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[57] ABSTRACT 

According to a broad aspect of a preferred embodiment of 
the invention, telephone calls, data and other multimedia 
information is routed through a hybrid network which 
includes transfer of information across the internet utilizing 
telephone routing information and internet protocol address 
information. The hybrid network includes an intelligent 
network solution which allows hybrid network service users 
to maintain the same experience and have access to the same 
information regardless of where or how they access the 
network. The solution avoids synchronicity management 
problems associated with replicating user data over a world- 
wide network. 
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SYSTEM, METHOD AND ARTICLE OF 
MANUFACTURE FOR CROSS-LOCATION 
REGISTRATION IN A COMMUNICATION 
SYSTEM ARCHITECTURE 

FIELD OF THE INVENTION 

The preseat invention relates to hybrid communication 
networks and more particularly to cross-network location 
registration whereby network users have access to the same 
information regardless of where or how they access the 
hybrid network. 

BACKGROUND OF INVENTION 

The current telecommunication service providers* net- 
works reflect the architecture of the PSTN network as it has 
evolved over the last 100 years. This is largely based on 
circuit switched technologies. Initially, all telecommunica- 
tion services were offered via a wired infrastructure. As the 
user-base increased and requirements changed over the last 
few decades, new types of services were created e.g. wire- 
less PSTN, cable video, multi-service (PSTN, video, 
satellite). The networks that supported these services were 
created as parallel networks, along-side the existing PSTN 
network. As technologies matured, there was some conver- 
gence (e.g. they shared the same SONET backbone) in the 
network architecture. During the late 1980s, with the explo- 
sion of data networking and Internet, data networking net- 
works like frame relay and ATM were developed, and later 
large internet based data networks were constructed in 
parallel with the existing PSTN infrastructure. These data 
networks again shared the PSTN infrastructure only at the 
SONET backbone layer. This state of current networks is 
called the existing "Core". Thus the "Core" network is a set 
of parallel networks; PSTN, wireless, satellite, cable, ATM, 
frame relay, IP. There is some interoperability between the 
services on these parallel network (e.g. PSTN, and wireless), 
but generally these networks are vertically integrated to 
provide distinct set of non-interoperable services. 

SUMMARY OF INVENTION 

According to a broad aspect of a preferred embodiment of 
the invention, telephone calls, data and other multimedia 
information is routed through a hybrid network which 
includes transfer of information across the internet utilizing 
telephony routing information and internet protocol address 
information. The hybrid network includes an intelligent 
network solution which allows hybrid network service users 
to maintain the same experience and have access to the same 
information regardless of where or how they access the 
network. The solution avoids synchronicity management 
problems associated with replicating user data over a world- 
wide network. 

DESCRIPTION OF THE DRAWINGS 

The foregoing and other objects, aspects and advantages 
are better understood from the following detailed description 
of a preferred embodiment of the invention with reference to 
the drawings, in which: 

FIG. lAis a block diagram of an exemplary telecommu- 
nications system in accordance with a preferred embodi- 
ment; 

FIG. IB shows a block diagram of the Network Data 
Management in accordance with a preferred embodiment; 

FIG. 1B-1 is a flowchart illustrating a Network Data 
Management process in accordance with a preferred 
embodiment; 

FIG. 1C shows a block diagram of the Customer Interface 
Management Process in accordance with a preferred 
embodiment; 



2 

FIG. 1C-1 is a flowchart illustrating a Customer Interface 
Management Process in accordance with a preferred 
embodiment; 

FIG. ID shows a block diagram of the Customer Quality 
5 of Service Management Process in accordance with a pre- 
ferred embodiment; 

FIG. 1D-1 is a flowchart illustrating a Customer Quality 
of Service Management Process in accordance with a pre- 
ferred embodiment; 
10 FIG. IE shows a block diagram of the Service Quality 
Management in accordance with a preferred embodiment; 

FIG. 1E-1 is a flowchart illustrating a Service Quality 
Management Process in accordance with a preferred 
embodiment; 

15 FIG. IF shows a block diagram of the Problem Handling 
Process in accordance with a preferred embodiment; 

FIG. 1F-1 is a flowchart illustrating a Problem Handling 
Management Process in accordance with a preferred 
embodiment; 

20 

FIG. 1G shows a block diagram of the Rating and 
Discounting Process in accordance with a preferred embodi- 
ment; 

FIG. 1G-1 is a flowchart illustrating Rating and Discount - 
25 ing Process in accordance with a preferred embodiment; 

FIG. 1H shows a block diagram of the Invoice and 
Collections Process in accordance with a preferred embodi- 
ment; 

FIG. 1H-1 is a flowchart illustrating an Invoice and 
30 Collections Process in accordance with a preferred embodi- 
ment; 

FIG. 2A is a flowchart showing illustrating media com- 
munication over a hybrid network in accordance with a 
preferred embodiment; 

35 FIG. 2B is a block diagram of an exemplary computer 
system in accordance with a preferred embodiment; 

FIG. 3 illustrates the CDR and PNR call record formats in 
accordance with a preferred embodiment; 

4Q FIGS. 4(A) and 4(B) collectively illustrate the ECDR and 
EPNR call record formats in accordance with a preferred 
embodiment; 

FIG. 5 illustrates the OSR and POSR call record formats 
in accordance with a preferred embodiment; 
45 FIGS. 6(A) and 6(B) collectively illustrate the EOSR and 
EPOSR call record formats in accordance with a preferred 
embodiment; 

FIG. 7 illustrates the SER call record format in accor- 
dance with a preferred embodiment; 
50 FIGS. 8(A) and 8(B) are control flow diagrams illustrat- 
ing the conditions under which a switch uses the expanded 
record format in accordance with a preferred embodiment; 

FIG. 9 is a control flow diagram illustrating the Change 
Time command in accordance with a preferred embodiment; 

FIG. 10 is a control flow diagram illustrating the Change 
Daylight Savings Time command in accordance with a 
preferred embodiment; 

FIG. 11 is a control flow diagram illustrating the Network 
6Q Call Identifier (NCID) switch call processing in accordance 
with a preferred embodiment; 

FIG. 12 is a control flow diagram illustrating the process- 
ing of a received Network Call Identifier in accordance with 
a preferred embodiment; 
65 FIG. 13(A) is a control flow diagram illustrating the 
generation of a Network Call Identifier in accordance with 
a preferred embodiment; 
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FIG. 13(B) is a control flow diagram illustrating the 
addition of a Network Call Identifier to a call record io 
accordance with a preferred embodiment; and 

FIG. 14 is a control flow diagram illustrating the transport 
of a call in accordance with a preferred embodiment; 

FIG. ISA is a flowchart showing a Fault Management 
Process in accordance with a preferred embodiment of the 
present invention; 

FIG. 15B is a block diagram showing a Fault Manage- 
ment component in accordance with a preferred embodiment 
of the present invention; 

FIG. 16 A is a flowchart showing a Proactive Threshold 
Management Process in accordance with a preferred 
embodiment of the present invention; > 

FIG. 16B is a flowchart showing a Network Sensing 
Process in accordance with one embodiment of the present 
invention; 

FIG. 17 is a flowchart showing an Element Management 
Process in accordance with a preferred embodiment of the 
present invention; 

FIG. 18 is a flowchart showing a three tiered customer 
support process in accordance with a preferred embodiment 
of the present invention; 

FIG. 19 is a flowchart showing an integrated IP telephony 
process in accordance with a preferred embodiment of the 
present invention; and 

FIG. 20 is a flowchart showing a Data Mining Process in 
accordance with a preferred embodiment of the present 
invention. 

DETAILED DESCRIPTION 

The following table is used to clarify terms used in the 
detailed description of the invention. 



AAA 


Authentication, Authorization, Addressing 


ADSL 


Asymmetric Digital Subscriber Line 


AIN 


Advanced Intelligent Networks 


AMA 


Automatic Message Accounting 


ATM 


Asynchronous Transfer Mode 


BIM 


Business Integration Methodology 


BSS 


Business Support System 


CDR 


Call Detail Record 


DTMF 


Dual-Tone Multi-Frequency 


GSM 


Global System for Mobile Communications 


IN 


Intelligent Network 


IP 


Internet Protocol 


JPEP 


Joint Picture Expert Group 


LMDS 


Local Multi-Point Distribution Service 


MPEG 


Moving Picture Expert Group 


NGN 


Next Generation Network 


OSS 


Operational Support Systems 


PCM 


Pulse Code Modulation 


PSTN 


Public Switched Telephone Network 


QoS 


Quality of Service 


RAS 


Remote Access Server 


SCE 


Service Creation Environment 


SCP 


Service Control Point 


SMDS 


Switched Multi Megabit Data Service 


SSP 


Service Switching Point 


SONET 


Synchronous Optical Network 


STP 


Service Transfer Point 


TCP 


Transmission Control Protocol 


xDSL 


Generic name for Digital Subscriber Line 


(D)WDM 


(Dense) Wave Division Multiplexing 
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Data networks today rely heavily on shared medium, 
packet-based LAN technologies for both access and back- 
bone connections. The use of packet switching systems, 
such as bridges and routers, to connect these LANs into 
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global internets is now widespread. An internet router must 
be capable of processing packets based on many different 
protocols, including IP, IPX, DECNET, AppleTALK, OSI, 
SNA and others. The complexities of building networks 
capable of switching packets around the world using these 
different protocols is challenging to both vendors and users. 

Standards-based LAN systems work reasonably well at 
transfer rates up to about 100 Mbps. At transfer rates above 
100 Mbps, providing the processing power required by a 
packet switch interconnecting a group of networks becomes 
economically unrealistic for the performance levels desired. 
This inability to economically "scale up" performance is 
beginning to cause restrictions in some user's planned 
network expansions. Also, today's data networks do not 
provide network managers with enough control over band- 
width allocation and user access. 

Tomorrow's networks are expected to support "multime- 
dia" applications with their much greater bandwidth and 
real-time delivery requirements. The next generation net- 
works should also have the ability to dynamically reconfig- 
ure the network so that it can guarantee a predetermined 
amount of bandwidth for the requested quality of service 
(QOS). This includes providing access, performance, fault 
tolerance and security between any specified set of end 
systems as directed by the network's manager. The concept 
is to provide network managers with complete "command 
and control" over the entire network's infrastructure — not 
just tell them when a failure has occurred. 

A new set of technologies known as asynchronous trans- 
fer mode (ATM) may provide the best:, long-term solution 
for implementing the requirements of both private and 
public internets. ATM promises to provide a more economi- 
cal and scalable set of technologies for implementing the 
ultra-high-performance information networks that will be 
required to provide the quality of service users will demand. 
Thus, over the next 20 years, the network infrastructure may 
change from packet-based standards to one based on ATM 
cell switching. While changes in the accompanying network 
will be dramatic, it would be desirable for users making the 
transition to be able to retain their most recent equipment 
investment. 

Another expected change in tomorrow's networks is a 
change in data flow. Data flow in today's network typically 
follows the client-server computing model. This is where 
many clients are all transferring data into and out of one or 
more network servers. Clients do not normally talk to each 
other; they share data by using the server. While this type of 
data exchange will continue, much more of the information 
flow in tomorrow's networks will be peer-to-peer. Since the 
ultimate goal is a truly distributed computing environment 
where all systems act as both the client and server, more of 
the data flow will follow a peer-to-peer model. The network 
will be required to provide more direct access to all peers 
wishing to use high-performance backbone internets 
connecting, for example, the desktop computers. 

The bulk of information transported in the future will be 
of digital origin. This digital information will require a great 
deal more bandwidth than today's separate voice, fax, and 
SNA networks which operate with acceptable performance 
using voice grade telephone lines. Voice will shrink as a 
percentage of total traffic, while other forms of information 
including image and video will greatly increase. Even when 
compressing is available, the bandwidth requirements for 
both inside and outside building networks will need to be 
greatly expanded. 

Text files and images can be sent over existing packet- 
based networks because the delivery of this information is 
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not time critical. The new traffic (voice and video) is 
delivery time sensitive — variable or excessive latency will 
degrade the quality of service and can render this informa- 
tion worthless. 

Hie usefulness of packet switching networks for the 
transmission of digital information, particularly burst type 
information, has long been recognized. Such networks are 
generally point-to-point in nature in that a packet from a 
single source is directed to a single destination by an address 
attached to the packet. The network responds to the packet 
address by connecting the packet to the appropriate desti- 
nation. 

Packet switching networks are also used which combine 
burst type data with the more continuous types of informa- 
tion such as voice, high quality audio, and motion video. 
Commercialization of voice, video and audio transmission 
makes it desirable to be able to connect packets to multiple 
destinations, called packet broadcasting. For example, a 
broadcast video service such as pay-per-view television 
involves a single source of video packets, each of which is 
directed to multiple video receivers. Similarly, conferencing 
capabilities for voice communication also require single 
source to multiple destination transmission. 

One prior packet broadcast arrangement comprises a 
network consisting of a packet duplication arrangement 
followed by a packet routing arrangement. As a broadcast 
packet enters this network, packet copies are made in the 
packet duplicating arrangement until as many copies exist as 
there are destinations for the packet. A translation table look 
up is then performed at the duplication arrangement outputs 
for each of the packet copies to provide a different, single 
destination address for each copy. All of the packet copies 
with their new packet addresses are then applied to the 
packet routing arrangement, which connects them to the 
appropriate network output ports. 

In packet switching networks, packets in the form of units 
of data are transmitted from a source — such as a user 
terminal, computer, application program within a computer, 
or other data handling or data communication device — to a 
destination, which may be simply another data handling or 
data communication device of the same character. The 
devices themselves typically are referred to as users, in the 
context of the network. Blocks or frames of data are trans- 
mitted over a link along a path between nodes of the 
network. Each block consists of a packet together with 
control information in the form of a header and a trailer 
which are added to the packet as it exits the respective node. 
The header typically contains, in addition to the destination 
address field, a number of subfields such as operation code, 
source address, sequence number, and length code. The 
trailer is typically a technique for generating redundancy 
checks, such as a cyclic redundancy code for detecting 
errors. At the other end of the link, the receiving node strips 
off the control information, performs the required synchro- 
nization and error detection, and reinserts the control infor- 
mation onto the departing packet 

Packet switching arose, in part, to fulfill the need for low 
cost data communications in networks developed to allow 
access to host computers. Special purpose computers des- 
ignated as communication processors have been developed 
to offload the communication handling tasks which were 
formerly required of the host. The communication processor 
is adapted to interface with the host and to route packets 
along the network; consequently, such a processor is often 
simply called a packet switch. Data concentrators have also 
been developed to interface with hosts and to route packets 
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along the network. In essence, data concentrators serve to 
switch a number of lightly used links onto a smaller number 
of more heavily used links. They are often used in conjunc- 
tion with, and ahead of, the packet switch. 

5 In virtual circuit (VC) or connection-oriented 
transmission, packet-switched data transmission is accom- 
plished via predetermined end-to-end paths through the 
network, in which user packets associated with a great 
number of users share h'nk and switch facilities as the 

10 packets travel over the network. The packets may require 
storage at nodes between transmission links of the network 
until they may be forwarded along the respective outgoing 
link for the overall path. In connectionless transmission, 
another mode of packet-switched data transmission, no 

1S initial connection is required for a data path through the 
network. In this mode, individual datagrams carrying a 
destination address are routed through the network from 
source to destination via intermediate nodes, and do not 
necessarily arrive in the order in which they were transmit- 

20 ted - 

The widely-used Telenet public packet switching network 
routes data using a two-level hierarchy. The hierarchy com- 
prises a long distance-spanning backbone network with a 
multiplicity of nodes or hubs, each of which utilizes a cluster 

25 of backbone switches; and smaller geographic area networks 
with backbone trunks, access lines and clustered lower level 
switches connected to each hub. Packet-switched data is 
transmitted through the network via VCs, using CCITT 
(International Telegraph and Telephone Consultative Com- 

30 mittee of the International Telecommunications Union) X.75 
protocol, which is a compatible enhancement of X.25 pro- 
tocol. 

For a communication session to proceed between the 
parties to a connection, it is essential that data be presented 

35 in a form that can be recognized and manipulated. The 
sequence of required tasks at each end, such as the format of 
the data delivered to a party, the rate of delivery of the data, 
and resequencing of packets received out of order, is gen- 
erally handled in an organized manner using layered com- 

40 munication architectures. Such architectures address the two 
portions of the communications problem, one being that the 
delivery of data by an end user to the communication 
network should be such that the data arriving at the desti- 
nation is correct and timely, and the other being that the 

45 delivered data must be recognizable and in proper form for 
use. These two portions are handled by protocols, or stan- 
dard conventions for communication intelligently, the first 
by network protocols and the second by higher level pro- 
tocols. Each of these protocols has a series of layers. 

50 Examples of layered architectures include the Systems Net- 
work Architecture (SNA) developed by IBM, and the sub- 
sequently developed Open Systems Interconnection (OSI) 
reference model. The latter has seven layers, three of which 
are network services oriented including physical, data link, 

55 and network layers, and the other four providing services to 
the end user by means of transport, session, presentation, 
and application layers, from lowest to highest layer. 

X.25 is an interface organized as a three-layered archi- 
tecture for connecting data terminals, computers, and other 

60 user systems or devices, generally refereed to as data ter- 
minal equipment (DTE), to a packet-switched network 
through data circuit terminating equipment (DCE) utilized to 
control the DTE's access to the network. The three layers of 
the X.25 interface architecture are the physical level, the 

65 frame level and the packet level. Although data communi- 
cation between DCEs of the network is routinely handled by 
the network operator typically using techniques other than 
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X.25, communication between the individual user system and one or more databases to its users, and may place a level 

and the respective DCE with which it interfaces to the of security on its database which differs from the level 

network is governed by the X.25 or similar protocol. In placed by other customers on their respective hosts and 

essence, X.25 establishes procedures for congestion control databases. In those instances, it is customary to make the 

among users, as well as call setup (or connect) and call s host responsible for security and access to itself and its 

clearing (or disconnect) for individual users, handling of associated database. Thus, a user might have access to 

errors, and various other packet transmission services within certain destinations in the network without restriction, but 

the DTE-DCE interface. no access to other destinations. 

X.25 is employed for virtual circuit (VC) connections, 

including the call setup, data transfer, and call clearing 10 Market Drivers 
phases. Call setup between DTEs connected to the network 

is established by one DTE issuing an X.25 call-request According to Yankee Group Research, network manage- 
packet to the related DCE, the packet containing the channel ment continue to increase, with network managers 
number for the logical connections, the calling and called spending an average of 45 percent of their budget on 
DTE addresses, parameters specifying the call ongoing network management, 20 percent on equipment, 
characteristics, and the data. The destination DCE issues an 35 percent on network transport services. It is a constant 
incoming call packet, which is of the same general format as battle t0 reduce mese costs Y et somehow improve overall 
the call-request packet, to the destination DTE, the latter service to their customers. Reducing overall network man- 
replying with a call- accepted packet. In response, the calling agement costs can be very difficult in today's business 
DCE issues a call-connected packet to its related DTE. At environment. Networks continue to become more complex, 
that point the call is established and the data transfer phase ^th more and more demands being placed on the network 
may begin by delivery of data packets. When the call is managers and planners. For example, the exponential 
compared, i.e., the session is to end, a call-clearing proce- growth of remote access has made their jobs more difficult, 
dure is initiated. as m e requirement to establish and manage connections for 
Prospective routing paths in the network are initially 9 , remote offices md telecommuters is often required without 
determined by a network control center, which then trans- additional personnel or budget resources. Unfortunately, 
mits these predetermined paths to the backbone switches as network managers and planners spend so much time m 
routing tables consisting of primary and secondary choices "nrefighting" mode, trying to support their complex 
of available links from each hub. The secondary choices are networks, that very little time is actually spent planning for 
viable only in the event of primary link failures, and the 30 ™ rk f owth a ? d enhancements Combined with this is 
specific secondary link selection is a local decision at the me fact mat ll 15 becoming difficult to keep highly skilled 
respective hub based principally on current or recent traffic employees given the demand for certain skills in the 
congestion patterns. The unavailability of an outgoing link marketplace, and the premiums that will be paid for those 
from a hub at the time of the call setup effects a clearing back skills - So > what 15 a network manager to do? More and more, 
of the VC for the sought call to the preceding hub. An 35 ^ m lookin g outside for hel P- 

alternative link is then selected by that hub, or, if none is The market for customer network management services is 

available there, the VC circuit is again cleared back to the generally referred to as Managed Networked Services 

next preceding hub, and so forth, until an available path is (MNS). Yankee Group estimates this market will estimated 

uncovered from the routing tables. Messages concerning to grow from $3B to 9B within the next three years. MNS 

link and/or hub failures are communicated immediately to 40 became the focus of service providers in 1995 as they saw 

the network control center, and that information is dis- revenues for frame relay network services double for two 

patched to the rest of the network by the center. years in a row. What began as a way to boost the popularity 

In typical present-day concentrators and packet switches, of frame rela y services by offering to lease and manage 

the data processing devices reside in a plurality of cards or routers has blossomed into a diverse set of services that are 

boards containing printed circuits or integrated circuits for 45 now closer to those associated with outsourcing, 

performing the various functions of the respective device in Yankee Group research shows that 37 percent of Fortune 

combination with the system software. Typically, the cards 1000 managers are already outsourcing or plan to outsource 

arc inserted into designated slots in cages within a console, their ongoing network operations management. In addition, 

with backplane access to a data bus for communication with it is the communications provider that is thought of as the 

one another or to other devices in the network. The VME bus 50 most likely provider for one-stop shopping services, 

is presently the most popular 16/32-bit backplane bus. The present invention's overall approach to implementing 

References from time to time herein to cards or boards will the NM/MNS market offering is two fold. The current 

be understood to mean the various devices embodied in such opportunity that presents itself is MNS. While this market 

cards or boards. opportunity for clients is large, they need assistance in 

Many public data networks (PDNs) offer little or no 55 understanding data network management — for years they 

security for communications between users and hosts or have been solely focused on voice. Additionally, they need 

other data processing devices within the network, in keeping to move into this market quickly in order to maintain and 

with the "public purpose" of the network and the desire for grow revenue. To this end, the present invention includes a 

accessibility by a large number of actual and prospective set of assets consisting primarily of job aids and software 

users. Where restrictions on access are necessary or 60 that can greatly reduce our clients lead time for service 

desirable, it is customary to assign each authorized user an implementation. 

identification (ID) number or a password, or both, which Secondly, the present invention assists service providers 

must be used to gain access to the host. More elaborate by providing them the tools to better manage their carrier 

security measures are necessary where access may be had to data networks — the packet switched networks of the future, 

highly confidential data. 6S The present invention significantly enhances and scales 

Some data communication networks involve a variety of MNS assets to address carrier network management in a data 

different customers each of whom makes available a host networking world. This solution template enables the con- 
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vergence of circuit and packet switching network control 
centers and workforces. 

The present invention's market offering suggests compa- 
nies take a graduated approach to delivering MNS. One end 
of the continuum consists of MNS for current network 5 
services, including leased lines, frame relay, and X.25. On 
the far end is outsourced MNS characterized by long-term 
contracts, involving hundreds of millions of dollars. The 
NM/MNS market offering is proposing our clients go 
beyond the management of the router and the WAN, and into 10 
the world of the local area network (LAN), even as far as the 
desktop and business applications. Service providers have 
been intimidated by these propositions in the past, since 
management of the LAN and its equipment and applications 
has clearly not been their forte. 

It is hard to describe a typical MNS engagement because 15 
this is such a new. There are three "entry points" in which 
the present invention can become involved in helping our 
companies to move into the MNS market: 
Business Strategy — Companies may look to the present 
invention for assistance in creating a business strategy 20 
for entering the MNS market. Typically, this type of 
engagement will defines a company's target market for 
MNS (small, mid-market, large) and defines the service 
offerings that are best suited for the company to offer. 
These engagements will be followed by analysis, 25 
design and implementation projects. 
Requirements Analysis — Companies may already have 
developed a concrete business strategy that defines 
which services they will offer within markets. In this 
case, the present invention's work will begin by help- 30 
ing define the company's network environment 
requirements. This work will be followed by design and 
implementation projects. 
Design and Implementation — Companies may be ready to 
move to the design and implementation phases of 35 
creating an MNS capability. Generally, the present 
invention will confirm that their network meets the 
requirements to provide the service, then assist the 
client in the designing and implementing an appropriate 
solution suite. 

40 

In an effort to clearly communicate exactly how we define 
NM/MNS we have created an online catalog of services. The 
present invention's solution is a continuous cycle that begins 
with the four major processes associated with NM/MNS. 
These processes drive the technology and the people com- 45 
ponents of the solution. Within each of these processes are 
a number of core functions and sub-functions. The MNS 
Online Catalog contains all of this information, including 
the supporting process, technology and organizational solu- 
tions for each function. 5Q 

Our solution is called the Managed Networked Services 
Integrated Solution (MNSIS) and has been developed using 
an approach which integrates Process, Technology, and 
People considerations. 

Process 5S 

At the highest level, there are four major processes that 
must be performed to manage any network: 

Service Planning 

Managing Change 

Operations Management 

Service Management 

Each process should be performed in order to provide a 
complete NM/MNS solution. As mentioned above, each 
process has a number of associated functions and sub- 
functions that provide the complete picture of the process. 65 
The major functions associated with each process are as 
follows. 
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Technology 

The main goal of the technology solution is to provide 
access to network information to make informed decisions. 
The present invention includes three layers of management: 
element management, information services management 
and presentation management. Every action starts with an 
incident. Processing is tailored to handling the incident with 
technology that responds to the unique characteristics of 
each incident. 

Element Manager 

The element manager communicates with the network 
elements to receive alarms and alerts through trapping 
and polling techniques. The element manager is the 
layer where the primary data reduction functions 
reside. At this layer, events received at the element 
manager will be filtered, aggregated and correlated to 
further isolate problems within the network. Informa- 
tion that is deemed critical to monitor and manage the 
network is translated into a standard object format and 
forwarded to the Information Services Manager. An 
element manager can be, but is not necessarily, soft- 
ware which adheres to open standards such as the 
Simple Network Management Protocol (SNMP) and 
the Object Management Group's (OMG) Common 
Object Request Broker Architecture (CORBA). 

Information Services Manager 

The information services manager provides the data man- 
agement and data communications between element 
managers and presentation managers. All information 
forwarded from the element managers is utilized by the 
information services manager to provide information to 
the network operators. The information services man- 
ager adheres to CORBA standards to provide ubiqui- 
tous information access via an Object Request Broker 
(ORB). The ORB allows the information services man- 
ager to share management information stored in dis- 
tributed databases. 

The information services manager stores critical manage- 
ment information into operational (real-time) and ana- 
lytical (historical) distributed databases. These data- 
bases provide common data storage so that new 
products can be easily inserted into the management 
environment. For example, if an event is received at an 
element manager that is deemed critical to display to a 
network user, the information services manager will 
store a copy of the alarm in the operational database 
and then forward the alarm to the appropriate network 
operator. 

Media and textual databases are also provided by the 
information services manager. The databases includes 
online manuals for administrative purposes, as well as 
for the maintenance specialists to access element spe- 
cific information. The databases also provide 
procedures, policies and computer based training to 
network users. 

The information services manager provides requested 
information (real-time and historical) to the network 
users via the presentation manager. 

Presentation Manager 

The presentation manager performs the function its name 
implies: the presentation of the information to an end 
user. Because different locations and job functions 
require access to different types of information, there 
are at least two types of display methods. The first is for 
graphic intensive presentations and the second is for 
nomadic use, such as field technicians. The first envi- 
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ronment requires a graphic intensive display, such as 
those provided by X-Windows/MOTIF. The second 
environment is potentially bandwidth poor where dial- 
up or wireless access may be used along with more 
traditional LAN access. This is also where browser 
technology is employed. 
People 

The people vision for the NM/MNS include an organiza- 
tion model for customer service support, the corresponding 
roles and responsibilities for this organization model and a 
conceptual design for workforce transformation to packet 
switching. 

Customer Service Support 

Customer service support provides a single point of 
contact that is customer focused. This single point of 
contact provides technical expertise in resolving cus- 
tomer incidents, troubles and requests. Generally a 
three tiered support structure is optimal for satisfying 
customer service needs. Each tier, or level, possesses an 
increasing level of skill, with tasks and responsibilities 
distributed accordingly. Such a structure is as follows: 
Tier 1 — typically has a broad set of technical skills and 
is the first level of support to the customer. Typically 
this group is responsible for resolving 60-70 percent 
of the opened problems. 
Tier 2 — are technical experts and field support person- 
nel who may specialize in specific areas. Typically 
this group is responsible for resolving 30-40 percent 
of the opened problems. 
Tier 3 — are considered solution experts and often con- 
sist of hardware vendors, software vendors or cus- 
tom application development/maintenance teams 
(in-depth skills needed to investigate and resolve 
difficult problems within their area of expertise). 
They are the last resort for solving the most difficult 
problems. Typically this group is responsible for 
resolving 5 percent or fewer of the opened problems. 
The above model is generally referred to as the Skilled 
Model because personnel at all three tiers are highly 
skilled. This model generally creates a high percentage 
of calls resolved on the first call. Other approaches 
include: 
Functional Model 

In this model, users are requested to contact different 
areas (via VRU) depending on the nature of the inci- 
dent. Calls are routed to the customer support repre- 
sentative best able to handle the call. This model can 
easily be coupled with the Skilled Model, and has been 
at previous client engagements. 

Bypass Model 

In this model, Tier 1 only logs calls, they do not resolve 
calls. One advantage of this model is that skilled 
resources don't have to waste time logging "calls. 

Software and Assets 

Managed Networked Services Integrated Solution — The 
integrated network management solution template con- 
sists of a suite of best of breed third party software 
products that automate problem diagnosis, notification, 
custom-developed reporting, and IP services monitor- 
ing. This solution template is a great first step in 
realizing our technology solution vision. 

Web -Based SLA Reporting Tool — is a browser based tool 
that provides the personalized SLA reports to custom- 
ers in both a template and ad-hoc format. 

Data Mining Demonstration — Provides the capability to 
analyze network management data looking for patterns 
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and correlations across multiple dimensions. Build 
models of the behavior of the data in order to predict 
future growth or problems and facilitate managing the 
network in a proactive, yet cost-effective manner. 
5 Customer to Event Mapping Module — Add-on module to 
the Managed Networked Services Integrated Solution 
which maps network element events, to service 
offerings, to customers. This tool allows the Customer 
Service Representative to proactively address network 
10 outages with customers. 

Process Definitions and Functions 

Service Planning 

Service Planning includes both the strategic and tactical 
planning required to manage distributed environments effec- 
15 lively. Although most planning typically occurs during roll- 
out of the system, certain planning activities must otherwise 
take place. Service Planning ensures that change can be 
successfully controlled and implemented. 
2Q Service Management Planning 

Operations Management Planning 

Managing Change Planning 

Strategic Planning 

Managing Change 
25 Includes processes and procedures for handling necessary 
changes to systems or the organization in a distributed 
environment. 

Change Control 

Testing 

Implementing 

Software Distribution 

Operations Management 

Systems Management consists of the day-to-day opera- 
35 tional functions required to maintain the system (e.g. fault 
detection/correction, security management and performance 
management). 
Production Control 
Monitoring and Control 
40 Fault Management 
Security Management 
Service Management 

Service Management controls the overall service to the 
users of the system. It isolates users from how the system is 
45 managed, and ensures that users receive the quality support 
services they need to carry out their daily business activities. 
SLA/OLA Management 
Help Desk 
50 Quality Management 
Billing and Accounting 

The present invention includes a system, method, and 

article of manufacture for providing a hybrid .circuit 

switched/packet switched network. This hybrid network is 
55 used as a transitioning network to transition from old "Core" 
network architectures to "New Core" networks. In the 
present description, the details of the NGN transitioning 
network will first be set forth after which details relating to 
specific billing aspects of the present invention will be 
60 described. 

PSTN, wireless, and cable networks have continued to 
grow at their organic rates determined by the growth of the 
vertical services they were providing. In the beginning, the 
data networks used a small portion of the backbone SONET 
65 bandwidth, while PSTN was still the dominant bandwidth 
user. Due to the exponential growth in IP traffic, the IP based 
data networks are soon slated to utilize more bandwidth than 



05/25/2004, EAST Version: 1.4.1 



6,081,518 



13 



14 



the PSTN. Also huge technical advances in packet technolo- 
gies have made it possible to carry traditional voice over IP 
networks. This has started a move towards the "Next Gen- 
eration Network (NGN)" where there will be more sharing 
of common network infrastructure to provide services, and 5 
these services will start to become more interoperable. The 
main thrust of technologies in the "NGN" will be to provide 
interoperability between the new packet based infrastructure 
and existing legacy infrastructures. Due to the large invest- 
ments made in the legacy infrastructure, they will continue 10 
to exist for some time, but most new innovations will occur 
on the packet based infrastructure. Slowly, the parallel 
networks that were created to serve distinct services will 
merge to use a common packet based backbone and only 
differ in how access is provided (wire -line, wireless, cable, 15 
satellite). The "NGN" is a transition network which will 
exist during the transformation from the current "Core" to 
the "New Core". 

As packet technologies continue to develop rapidly, it will 
be possible to support what was once a distinct set of 2 o 
services (voice, video, wireless) on separate parallel 
networks, on one integrated packet based network. There 
will still be separate access technologies (wireless, satellite, 
cable, wire-line) to access these services, but the access 
networks will all use a common "New Core" network and its 25 
capabilities. The services will be interoperable across vari- 
ous access technologies, and users will freely use services 
that cross many access technologies, e.g. wireless to cable 
phone services, web browsing from wireless devices etc. 

The present invention maps a course for the network 
evolution from circuit to packet switched technology using 
a migratory approach in which the network becomes a 
hybrid circuit and packet topology over a 3 to 7 year period. 

Next, the network architecture for the wire-line network 
as it transforms from "Core" to "NGN" to "New Core" will 
be described. Followed by architecture for cable, wireless 
and satellite based access networks. 

The Wire -line Network Architecture 

"Core" Network Architecture 

The current wire-line "Core" network consists of parallel 
PSTN, SMDS, ATM, Frame-Relay, B/PRI and IP net- 
works. The PSTN network has been evolving over the 
last century and is a mix of old and new circuit 
switched technologies. The PSTN network mainly pro- 
vides point-to-point interactive two-way voice commu- 
nication services. The service set has evolved to include 
many intelligent network (IN) service features. During 
the late 1980s, Advanced Intelligent Networks (AIN) 
emerged as the architecture to support new voice based 
services on the PSTN infrastructure. 
IN requirements and architecture in the current "Core" 
The major IN requirements include session 
_ establishment, advanced call processing, call routing 
and call treatment (network messages and call 
termination). Examples of applications and features 
are the CLASS family of services (Call waiting, Call 
forwarding, Conference calling, Call rejection), 
enhanced call routing, Number Portability, Calling 
Card Services, and Audio delivered Information Ser- 
vices (e.g. travel, stocks and weather). 
These IN capabilities are enabled by devices such as 
SCP, STP, SSP and EIP in the AIN environment. 
These devices participate in the execution and 
completion of an IN service. In order to develop, test 
and launch new IN service applications on the above 
mentioned components, service providers deploy 
Service Creation Environment (SCE) platforms, 
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which provide an environment to quickly create new 
IN services. These SCE platforms are closely tied to 
the runtime environment and therefore with very few 
exceptions become a major undertaking and a com- 
plex coordination effort to launch a new or modified 
IN service in the "Core" network environment. 
Data networks in the "Core" 
While the PS1N was growing in feature functionality 
as well as traffic demand, new data networks have 
been created to support the inter-networking of com- 
puting devices. These data networks provide inter- 
connection to geographically dispersed computing 
devices at varying levels of transmission bandwidth 
(e.g. 56/64K, T-l/E-1, T-3/E-3, OC-3/STM-1). The 
data networks consist of many technologies e.g. 
SMDS, ATM, frame-relay and IP. In some cases, 
these data networks themselves are parallel 
networks, in other cases, they share a common 
technology in the backbone (e.g. ATM can be the 
backbone for frame relay and IP data networks). 
These data networks share the same SONET based 
backbone with the PSTN network. The services on 
the PSTN and the data networks are very distinct and 
non-interoperable (example: voice versus web 
access). 

With the rapid explosion of the Internet, and innovation 
in packet based technologies, the IP based data 
network has become the dominant network in terms 
of user traffic, and its growth is slated to continue 
exponentially. This phenomenon has created a 
dilemma for traffic planners and engineers of the 
Core network. They have seen traffic grow on the 
access portions of their networks (PSTN) but have 
realized very little financial benefits from this usage 
because third party service providers have been the 
termination point of these internet data users. The 
incumbents have began to devise intelligent network 
solutions for this data traffic (example RAS with SS7 
gateway) in order to solve two major challenges: 1) 
off loading data traffic from the voice infrastructure 
to alleviate the congestion issues that face traditional 
voice customers and 2) collecting revenues from the 
third party data services providers (ISP's) for access 
and routing callers to their Points Of Presence. 
Due to the high growth in IP and other data services, 
many new service providers have emerged that are 
building only IP based data networks, and provide 
only IP based data services. Their business strategy 
is to continue to ride the technological innovation of 
IP and packet based technologies and build complete 
suites of services on a packet based infrastructure. 
Because they are investing in only one form of 
network (as opposed to many parallel networks), 
their unit cost of services is low, they are not 
encumbered by legacy networks and systems, and 
they can provide cheaper and better services to 
customers; hence they pose a significant threat to 
incumbent telecom service providers. 
"Next Generation Network" Architecture 
As packet based technologies continue to develop and 
provide the services that were only available on other 
networks (e.g. PSTN, cable), and new (green field) 
service providers continue to exploit their advantage, it 
has become necessary for many incumbent service 
providers to transition their "Core" network to the 
"Next Generation Network", where they can share the 
rapid technical advantages of packet technologies, and 
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improve their cost structure, and at the same time offer 

new services on the "Next Generation Network". 
New IP based services in the "NGN" 

While there are components in the NGN that ensure 
interoperability between "NGN" and PSTN, there 5 
are also a huge new set of new services that are built 
entirely on the NGN components which is provide 
feature rich multimedia (voice, video, data) based 
communication services as well as enabling many JQ 
E-Commerce services enabled by IP technologies. 
These components (described later in detail) include 
directories, policies, user authentication, 
registration, and encryption. These components 
enable services like integrated messaging, multime- 15 
dia conversations, on-demand multi-point 
conference, enhanced security & authentication, 
various classes of media transport services, numer- 
ous automations in electronic internet commerce 
activities e.g. banking, shopping, customer care, 2 o 
education, etc. As the NGN matures third party value 
added service providers will develop IP based ser- 
vices that will combine applications such as elec- 
tronic commerce (procurement, warehousing, distri- 
bution and fulfillment) as well as online banking to 25 
present the consumer with an integrated boundless 
shopping experience. 
Growth of bandwidth in the "NGN" 

In addition to new service features, the NGN also 
employs the use of new wire-line broadband access 30 
technologies, notably XDSL. Traditional wire-line 
access technologies will continue to be deployed at 
higher and higher speeds; wire -line access will move 
from predominantly T-l speeds to T-3 and OC-n 
speeds. These new broadband access technologies 35 
will increase the need for higher bandwidth in 
"NGN" core. The "NGN" core continues to use a 
SONET backbone, but will gradually move to using 
(D)WDM technologies to provide the bandwidth 
required to support broadband access. 40 

New and emerging technologies such as Giga-Bit Eth- 
ernet and Wire Speed IP may find their way to the 
network backbone, but not until Giga-bit Ethernet 
technology matures to handle a wide array of net- 
work services such as connection oriented circuit 45 
emulation. The use of Wire Speed IP technology is 
suitable for an enterprise network but lacks the 
robustness and scalability needed for carrier grade 
backbones. For this reason, there will always be a 
need for ATM in the backbone. 50 

The architecture in the "NGN" provides seamless 
interoperability of services between the packet based 
network and the traditional PSTN. New "NGN" 
packet based capabilities will be developed to sup- 
port AIN type features, while inter-operating with 55 
legacy PSTN/SS7/AIN. Large scale innovation in 
the IP based IN type capabilities (e.g. global number 
transparency, utilization of web based information, 
rich media communications) will create new services 
for IP enabled communication devices. Innovations 60 
on the PSTN will occur slowly, and may be restricted 
to maintaining interoperability of legacy PSTN with 
"NGN". In many cases, legacy PSTN components 
(e.g. SSP, SCP) will continue to evolve so that they 
can use common IP based packet switching tech- 65 
nologies (e.g. IP, TCP, UDP), as opposed to using 
existing circuit switched technologies (e.g. MTP). 
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IN requirements and architecture in the Next Generation 
Network (NGN) 

Given the huge revenues and global nature of PSTN 
services, as well as their use of SS7 and AIN 
technologies, components that allow interoperability 
between "NGN" and PSTN will need to be devel- 
oped. These will include IP/PSTN Gateways, 
IP/PSTN address translators, IP/SS7 Gateways, IP 
enabled SSP's, and IP based Intelligent Peripherals. 
In addition to IN enablers, new components (as will 
be describe later) with features like directories, 
policies, user authentication, registration, session 
encryption, etc. will also be developed to enhance 
the IN capabilities. The NGN-IN enablers will pro- 
vide the next level of intelligence in order to address 
communication over mixed media types, control of 
multiple session characteristics, collaborative com- 
munications needs, ubiquitous network access, "any 
to any" communications, and multimedia delivered 
information services. Note that these "NGN" com- 
ponents will continue to evolve to provide similar 
and enhanced capabilities in the "New Core". 
The following provides a description of new components 
in the "NGN" and the "New Core" that provide 
enhanced IP based services. The Intelligent IP (f*P) 
Network enablers are categorized as follows: 
Session Control (Bandwidth, Switching and Routing) 
Media Control (Call Treatment such as media 
conversion) 

Policy Management (Directory, Access control, 
Security) 

Bandwidth Management (Transport and real time 
restoration) 

The components for the "NGN" are described as indi- 
vidual functional units but may be combined for prac- 
ticality on individual network devices as the require- 
ments dictate. These components have been designed 
to operate in a distributed network environment to 
increase the flexibility of the NGN and New Core. The 
architecture provides a robust, secure and isolated 
messaging infrastructure for delivering control plane 
information to these devices. 
This infrastructure includes a well defined message set for 
accessing the functions that are provided by these 
components and data that resides in the rules database. 
The control plane architecture is efficient and has a 
unique mechanism for sharing service, user and control 
data without duplication. This permits mobile NGN 
service users to maintain the same experience and have 
access to the same information regardless of where or 
how they access the network. 
Example: FIG. 1A illustrates an exemplary telecommu- 
nications system 102 across the U.S. and a second 
network 103 in Europe. Assuming a U.S. based NGN 
service user was roaming in Europe and wanted to 
access the network but has the use of specific calling 
information stored in his profile database in the U.S., 
how would such a challenge be overcome without 
replicating the user's data onto every rules database on 
the NGN to ensure that the user would not be denied 
access to features and services which the user typically 
subscribed. Obviously, storing or replicating this data 
and then managing synchronicity over a worldwide 
network would be process intensive, costly and cum- 
bersome. This intelligent network architecture 
addresses these issues efficiently with mechanisms that 
make remote data available locally for the duration of 
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a session and then caches the information in short term 
non-volatile memory not in the foreign rules database 
server. In other words although a user's profile may be 
physically stored in a Rules database 105 in the U.S., 
the user may access the network from Europe and be 
automatically granted access to the specific services 
and features that normally would be available during 
his U.S. service experience. The remote session con- 
troller 107 in Europe would communicate with the 
cross network location register and rules database 
server to identify the subscriber's "home" rules data- 
base in order to collect the policies and profile of the 
subscriber for use in Europe; this is done by using the 
inter device message sets (command and control) over 
the control plane sub network. Unlike other mecha- 
nisms often employed, this mechanism does not repli- 
cate this information onto the local (European) rules 
database, making long term control data management 
predictable. The design is CORBA compliant and 
therefore can be interconnected with other standards 
based networks. 

Rules Database server 

Determines Subscriber Profile 
Session requirements such as Bandwidth, Quality Of 

Service, Class Of Service 
Routing preferences based on Priority, Cost, Termina- 
tion Location 

Media and Application requirements (Voice Telephone 
to Video Telephone, Multi-point, text to speech, Fax 
to E-mail etc.) 
Content Separation (Example: Tells the intelligent 
peripheral and protocol converter to separate the 
Audio stream from the data and video stream on an 
H.32x call; It may also instruct the protocol con- 
verter to process the stream so as to enable this audio 
stream to be fed to a destination which supports 
traditional analog voice hence the G.728/9 content 
from the H.32x session would be converted first to 
AD/PCM and then sent to a Class 5 circuit based 
switch and terminated on a circuit switched SS7 
network POTS line) 
Access Device (Session Control) 
Provides connectivity and session termination from cus- 
tomer premises to the NGN 
Acts as the hub for the various applications (Video, Voice, 

Fax, Web Data, Unified Messaging) 
Provides systems management and reporting functions 
May provide application multiplexing (allowing simulta- 
neous multi application access) 
Intelligent Peripheral 109 (Media Control) 
Provides services such as DTMF parsing, Voice 
prompting,. Messaging,. Speech recognition, Text to 
Speech, Text to Fax, etc. 
Protocol Conversion 111 (Policy Management) 
Receives session requirements from Rules database 
Selects and executes required filters to enable activation, 

processing and tear-down of sessions 
Interfaces with existing CORE network to process infor- 
mation across NGN/Extended CORE 
Filters and Converts signals from SS7/ISDN to TCP/IP/ 
H.323 

Converts Signaling data from one format to another 
(example: G.728/9 to AD/PCM or Vocaltec to Vienna 
Systems, etc.) 

Network Access Control Point (Session Control) 
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Similar to a switching node on an SS7 circuit switched 
network. 

First or Last Access Point in the network 

Provides actual call/session handling, routing and pro- 
cessing based on instructions from the Rules Database 
server 

Session Manager/Event Logger (Session Control) 
This process or application is critical since it is the "glue" 
between the end user application and the communica- 
tions network. It is responsible for collection and 
distribution of end-user session preferences, applica- 
tion requirements, access device capability and 
accounting policy information to the required "IN 
enabling" components. In summary its main functions 
are to: 

Create the AMA/CDR and other usage records 
Interfaces external 3 rd party Network Gateways. 
Liase with Clearing Houses and Cross Network Loca- 
tion Registers 
Feeds the Financial Infrastructure 
Cross Network (Roaming) Location Register (Policy 
Management) 

Similar to the Home location register in the wireless/ 
cellular telephony world. This functional component 
provides the required policies governing users who 
access third party networks and cross geographical 
boundaries. It keeps in constant contact with other 
cross network location registers of the geographically 
dispersed but inter-connected networks, exchanging 
accounting, service feature profile and control data for 
local and roaming subscribers. 

"New Core" Network Architecture 

Most of the attributes of the "New Core" will already be 
in place as part of "NGN". These include all intelligent 
components of the packet based "NGN" described 
above. The emergence of "New Core" signals the 
retirement of legacy PSTN network infrastructure. The 
traditional PSTN may never get removed from the 
public network, it may continue to be available as a 
universally accessible telecommunication service, 
highly subsidized and regulated by government agen- 
cies (AMTRAK model). But for the purposes for 
business and technical innovation, traditional PSTN 
network will largely become irrelevant. 

As the PSTN based access methods go away, entirely IP 
based access methods will emerge in the "New Core", 
where all end devices connected to the "New Core" are 
IP enabled. All existing methods of wire-line based 
access (XDSL, T-l, T-3, fiber) will continue to provide 
access to IP based services over the "New Core". New 
access technologies (e.g. power-line) will emerge, but 
will still use the same packet based capabilities in the 
"New Core". 

The trends observed in the "NGN" will continue with 
increased broadband access. Other access methods 
(cable, satellite, wireless) will also complete their trans- 
formation to the "New Core". These will all become IP 
enabled access technologies that will use the "New 
Core" for complete set of services, thus really provid- 
ing seamless services across many different access 
technologies. 
The Wireless Data Network Architecture 
The current wireless "Core" network consists of wireless 
based access and roaming capabilities that inter-operate with 
wire-line PSTN "Core" infrastructure to provide interoper- 
able PSTN services. As the PSTN migrates to "NGN" and 
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"New Core", the wireless PSTN access infrastructure will 
also migrate to connect to "NGN" and "New Core" to 
provide wireless PSTN access services while utilizing new 
capabilities in the "NGN" and the "New Core". There will 
also be innovations in the wireless end-devices such that 5 
they will become IP enabled, and will thus allow a broad 
range of innovations by allowing mobility to the wire -line IP 
based service capabilities (e.g. web browsing, e-mail etc.). 
These wireless access methods to the "New Core" will be 
restricted to lower speeds due to the legacy nature of this 
wireless infrastructure while new broadband wireless access 
may emerge to provide a new set of IP enabled wireless 
devices that can provide broadband services over wireless/ 
mobile devices. In Europe, significant improvements in 
technologies such as GSM have provided insight into some 
NGN and New CORE capabilities such as 300 Kilobits of 15 
access bandwidth to deliver information to hand-held wire- 
less devices. The potential of such capabilities coupled with 
the traditional strengths of wireless communications such as 
roaming and error handling enabled by digitization, at this 
stage seems limitless when aggregated with the intelligence 20 
of the NGN and New CORE backbone. 

LMDS is an emerging technology in the local high speed 
wire-less access, which utilizes the 25-35 GHz microwave 
spectrum for point to point and point to multi-point com- 
munications. Hie end users either share an antenna con- 25 
nected to a digital receiver which is connected to a channel 
bank. The application server be it voice (PBX), video 
(CODEC), or Data (Router or Switch) interfaces with the 
NGN via the channel bank. A session originates from the 
application which interacts with the server to request authen- 30 
tication (AAA), then a session is established between origi- 
nator and destination application by routing the call through 
the NGN components such as Gateways and Switches. 

The Emerging Satellite Data Network Architecture 

In addition to the wireless access infrastructure, new 35 
service providers have emerged that are trying to use low 
earth orbiting satellites (LEOS) to build a new access as well 
as backbone network infrastructure. The earlier version of 
these networks were built using traditional PSTN service 
model, hence they lack the bandwidth scalability for data 40 
services. In the "New Core", these will migrate to new 
packet switched based broadband LEO infrastructure, which 
will provide both high speed access as well as high speed 
backbone in the packet based "NGN" and "New Core". A 
satellite based broadband access mechanism will also be 45 
very suitable for multi-point services that will be developed 
on the "New Core". 

The Cable Network Architecture 

Cable networks were developed for mainly broadband 
broadcast of analog video entertainment services. The cur- 50 
rent "Core" cable infrastructure is suitable to serve one way 
video broadcast. Cable service providers are now upgrading 
their cable infrastructure to support high speed internet 
access. Thus in the "NGN" scenario for cable networks, 
cable will provide a new access mechanism for IP services, 55 
while simultaneously transport video content using the cur- 
rent video broadcast technology. Thus the IP enabled devices 
attached to the "NGN" cable infrastructure can take advan- 
tage of all the new components and capabilities described in 
the wire-line "NGN". This will enable seam-less services 60 
between devices that are accessing the "NGN* via a wire- 
line or cable infrastructures. This "NGN" cable infrastruc- 
ture can provide IP based telephony services using the same 
components of the wire-line "NGN" that provide IP tele- 
phony to wire-line IP devices. 65 

The digital network segment that interfaces with the 
"NGN" comprises of a coaxial cable local loop which is 
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connected to a cable data modulator running QAM/DPSK 
protocols. The coaxial loop is terminated at the customer 
premise by an Ethernet cable modem which delivers the IP 
Tone to the applications (Voice, Video, Data) that may reside 
on a PC or application server. The cable modems used 
provide users and applications with a wide range of band- 
width options from 2 to 10 Mbits per second depending on 
configuration and choice of equipment vendor. 

With the evolution of the "New Core" in the wire-line, the 
cable will continue to provide another broadband access 
mechanism for IP based services. As the "New Core" 
matures and enhances in capabilities (probably 10 years 
away), such that it can provide high speed real-time video 
content (to provide same quality as cable), it can be envis- 
aged that the cable will becomes an entirely IP access 
mechanism (just like all wire-line access becomes an IP 
access mechanism). Then the broadcast video content will 
be delivered to IP enabled cable attached devices just like 
any other rich media will be delivered over the IP network. 
It is even conceivable that video encoding technologies such 
as MPEG2 and motion JPEG will be further improved to 
deliver higher resolution digital media over the cable infra- 
structure using NGN and CORE delivery mechanisms. The 
network becomes transparent and the applications and con- 
tent drive the creativity of the service creation process. The 
PSTN like services will be delivered to devices connected 
via cable access just like they are delivered to other wire-line 
connected devices on the "New Core". 

NGN Creation Strategy 

The network transformation plan comprises of the fol- 
lowing phases 
Strategy 
Market Trial 
Service Launch 

Consolidation and Optimization 
Strategy 

Determine where our current network fits in the evolu- 
tionary continuum from CORE to NGN or New CORE. 
Having identified the appropriate positioning of the 
network, select an architectural scenario that best 
serves business and technical objectives of the engage- 
ment. 

Market Trial 

Develop and launch a market trial that would measure and 
assess the viability of the introduction of the proposed 
service. Additionally, this trial validates the approach to 
transform specific parts of the infrastructure towards 
the "NGN" and "New Core". The market trial provides 
the entry-exit criteria, metrics, Key Performance Indi- 
cators etc. to assess the success of the market trial. 

Service Launch 

Develop, plan and manage the detailed network, systems, 
process and program management aspects of the launch 
of a "New Core" that is applicable for the network 
based on the strategy developed above. This ensures 
that the network systems planned and developed will be 
future-ready. The OSS and back-office systems are be 
able to support the processes required for service 
creation and management in the "New Core". The 
network creation processes provides the program man- 
agement tools to ensure that the launch is successfully 
executed. These include entry and exit criteria for 
network creation, KPIs for quality management, pro- 
gram planning and management tool-kits. 

Service Consolidation and Optimization 

As the network operator moves into operating and main- 
taining the "NGN", there will be many parallel market 
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driven journeys during which services and capabilities Discounting) processes at the Service Management Layer, 

will be developed for the "NGN". The network creation depending on the service and its architecture, 

process provides tools to assist the client into improv- The process provides sufficient and relevant information 

ing efficiencies of these parallel journeys. These opti- to verify compliance/non-compliance to Service Level 

mization efforts will include organizational, process 5 Agreements (SLA). The process provides sufficient usage 

and technology driven changes to create efficiency information for rating and billing, 

based on consolidation of processes, as well as mea- This process ensures that the Network Performance goals 

surement tools to determine the success of such con- are tracked, and that notification is provided when they are 

solidation. The network architecture roadmap and busi- not met (threshold exceeded, performance degradation), 

ness blueprint will act as the foundation to ensure that 10 This also includes thresholds and specific requirements for 

during the consolidation phase the "NGN" maintains billing. This includes information on capacity, utilization, 

the required architecture framework to sustain it for the traffic and usage collection. In some cases, changes in traffic 

long term. conditions may trigger changes to the network for the 

Now that the details regarding the NGN have been set purpose of traffic control. Reduced levels of network capac- 

forth, information will now be presented concerning billing 15 ity can result in requests to Network Planning for more 

when the quality of service is degraded. resources. 

Degraded Quality of Service and Billing FIG. 1B-1 is a flowchart illustrating a network data 

A typical telecommunication network comprises multiple management process in accordance with a preferred embodi- 

telecommunication switches located throughout a geo- ment. First, in step 150, data is collected relating to usage 

graphical area. When a user makes a call, the call may be 20 and events occurring over a hybrid network. Next, in step 

routed through one or more switches before reaching its 152, the data is analyzed to determine a status of the hybrid 

destination. network which in turn, in step 154, is utilized during 

FIG. 1A illustrates an exemplary telecommunications management of the hybrid network. Further, in step 156, 

system 102 across the U.S. For purposes of illustration, a billing rates and discounts are determined based on the 

caller 104 places a call from Los Angeles, Calif, to a party 25 status of the hybrid network. 

112 located in New York City, N.Y. Such a call is typically In addition to the Network Data Management 130 gen- 
transmitted across three (3) switches: the Los Angeles, Calif, erating billing events, the present invention also uses a 
switch 106; the Chicago, 111. switch 108; and the New York Customer Interface Management process 132, as shown in 
City, N.Y switch 110. In this scenario, the originating switch FIG. 1C, to directly interact with customers and translate 
is the Los Angeles, Calif, switch 106, and the terminating 30 customer requests and inquiries into appropriate "events" 
switch is the New York City, N.Y. switch 110. such as, the creation of an order or trouble ticket or the 

Each of the switches, 106-110, is connected to two (2) or adjustment of a bill. This process logs customer contacts, 

more Data Access Points (DAP) 116-120, for instance a directs inquiries to the appropriate party, and tracks the 

primary DAP 116-120 and a backup DAP 116-120. A DAP status to completion. In those cases where customers are 

116-120 is a facility that receives requests for information 35 given direct access to service management systems, this 

from the switches 106-110, processes the requests, and process assures consistency of image across systems, and 

returns the requested information back to the requesting security to prevent a customer from harming their network 

switch 106-110. The switches 106-110 use information or those of other customers. The aim is to provide mean- 

from the DAPs 116-120 to process calls through the net- ingful and timely customer contact experiences as frequently 

work. 40 as the customer requires. 

When a call passes through one of the switches, 106-110, FIG. 1C-1 is a flowchart illustrating a Customer Interface 

that switch creates a call record. The call record contains Management Process in accordance with a preferred 

information on the call, including but not limited to: routing, embodiment. First, in step 158, a service level agreement is 

billing, call features, and trouble shooting information. After received for a hybrid network customer. Next, in step 160, 

the call is terminated, each switch 106-110 that processed 45 the service level agreement is stored after which, in step 162, 

the call completes the associated call record. The switches inquiries are received from network customers reflecting 

106-110 combine multiple call records into a billing block. occurrences related to the hybrid network. Thereafter, in step 

When a switch 106-110 fills the billing block, the switch 164, events are generated based on the customer inquiries 

106-110 sends the billing block to a billing center 114. Thus, and the service level agreement. 

the billing center 114 receives one billing block from each 50 The Network Data Management 130 and Customer Inter- 
switch 106-110 that handled the call, which in this case face Management process 132 are used to give information 
would be three billing blocks. The billing center 114 to the Customer Quality of Service Management Process 
searches each billing block and retrieves the call record 134, as shown in FIG. ID. The Customer Quality, of Service 
associated with the call, thereby retrieving one call record Management Process 134 encompasses monitoring, manag- 
per switch 106-110 that handled the call. The billing center 55 ing and reporting of quality of service as defined in Service 
114 then uses one or more of the retrieved call records to Descriptions, Service Level Agreements (SLA), and other 
generate a billing entry. The billing center 114 is also service-related documents. It includes network performance, 
connected to each DAP 116-120 to retrieve information but also performance across all of service parameters, e.g., 
regarding a switch 106-110 or call record. However, billing Orders Completed On Time. Outputs of this process are 
in the present invention is increased because the hybrid 60 standard (predefined) and exception reports, including; 
network also contains proxy intelligence. dashboards, performance of a service against an SLA, 
FIG. IB shows a block diagram of the Network Data reports of any developing capacity problems, reports of 
Management 130 in accordance with a preferred embodi- customer usage patterns, etc. In addition, this process 
ment of the present invention. Network Data Management responds to performance inquiries from the customer. For 
130 encompasses the collection of usage data and events for 65 SLA violations, the process supports notifying Problem 
the purpose of network performance and traffic analysis. Handling and for QoS violations, notifying Service Quality 
This data may also be an input to Billing (Rating and Management 136. The aim is to provide effective monitor- 
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ing. Monitoring and reporting must provide SP management 
and customers meaningful and timely performance informa- 
tion across the parameters of the services provided. The aim 
is also to manage service levels that meet specific SLA 
commitments and standard service commitments. 

FIG. 1D-1 is a flowchart illustrating a Customer Quality 
of Service Management Process in accordance with a pre- 
ferred embodiment. First, in step 166, a hybrid network 
event is received which may include customer inquiries, 
required reports, completion notification, quality of service 
terms, service level agreement terms, service problem data, 
quality data, network performance data, and/or network 
configuration data. Next, in step 168, the system determines 
customer reports to be generated and, in step 170, generates 
the customer reports accordingly based on the event 
received. 

FIG. IE shows a block diagram of the Service Quality 
Management 136 in accordance with a preferred embodi- 
ment of the present invention. The Service Quality Man- 
agement Process 136 supports monitoring service or product 
quality on a service class basis in order to determine 
Whether service levels are being met consistently 
Whether there are any general problems with the service 
or product 

Whether the sale and use of the service is tracking to 
forecasts. 

This process also encompasses taking appropriate action 
to keep service levels within agreed targets for each service 
class and to either keep ahead of demand or alert the sales 
process to slow sales. The aim is to provide effective service 
specific monitoring, management and customers meaningful 
and timely performance information across the parameters 
of the specific service. The aim is also to manage service 
levels to meet SLA commitments and standard commit- 
ments for the specific service, 

FIG. 1E-1 is a flowchart illustrating a Service Quality 
Management Process in accordance with a preferred 
embodiment. First, in step 172, a hybrid network event is 
received that may include forecasts, quality objectives, 
available capacity, service problem data, quality of service 40 
violations, performance trends, usage trends, problem 
trends, maintenance activity, maintenance progress, and/or 
credit violations. Next, in step 174, quality management 
network data is determined and, in step 176, the quality 
management network data is generated. Such quality man- 45 
agement network data may include constraint data, capacity 
data, service class quality data, service modification 
recommendations, additional capacity requirements, perfor- 
mance requests, and/or usage requests. Finally, in step 178, 
a network process to which to send the generated data is 
identified. 

FIG. IF shows a block diagram of the Problem Handling 
Process 138. The Problem Handling Process receives infor- 
mation from the Customer Interface Management Process 
132 and the Customer Quality of service Management 
Process 134. It is responsible for receiving service com- 
plaints from customers, resolve them to the customer's 
satisfaction and provide meaningful status on repair or 
restoration activity. This process is also responsible for any 
service -affecting problems, including 

notifying the customer in the event of a disruption 
(whether reported by the customer or not), 

resolving the problem to the customer's satisfaction, and 

providing meaningful status on repair or restoration activ- 
ity. 

This proactive management also includes planned mainte- 
nance outages. The aim is to have the largest percentage of 
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problems proactively identified and communicated to the 
customer, to provide meaningful status and to resolve in the 
shortest timeframe. 

FIG. 1F-1 is a flowchart illustrating a Problem Handling 
Management Process in accordance with a preferred 
embodiment. First, in step 180, a notification of a problem 
within a hybrid network is received by the system. Next, in 
step 182, a resolution for the problem within the hybrid 
network is determined. The resolution may include a status 
report, resolution notification, problem reports, service 
reconfiguration, trouble notification, service level agreement 
violations, and/or outage notification. Finally, in step 184, 
the progress of the implementation of the resolution is 
tracked. 

The Problem Handling Process 138 and the Network Data 
Management 130 feed information to the Rating and Dis- 
counting Process 140, as shown in FIG. 1G. This process 
applies the correct rating rules to usage data on a customer- 
by-customer basis, as required. It also applies any discounts 
agreed to as part of the Ordering Process, for promotional 
discounts and charges, and for outages. In addition, the 
Rating and Discounting Process 140 applies any rebates due 
because service level agreements were not met. The aim is 
to correctly rate usage and to correctly apply discounts, 
promotions and credits. 

FIG. 1G-1 is a flowchart illustrating Rating and Discount- 
ing Process in accordance with a preferred embodiment. 
First, in step 185, hybrid network customer usage informa- 
tion is received. In step 186, network service level agree- 
ment violations are collected, and, in step 187, network 
quality of service violations are received by the Rating and 
Discounting system. Next, in step 188, rating rules are 
applied to the network customer usage information. Further, 
in step 189, negotiated discounts are determined based on 
the network quality of service violations and, in step 190, 
rebates are determined based on the network service level 
agreement violations. Thereafter, in step 191, billing data 
reflecting the usage information, the negotiated discounts, 
and the rebates is provided to generate a customer invoice. 

Utilizing information from the Rating and Discounting 
Process 140, the Invoice and Collections Process 142, as 
shown in FIG. 1H, creates correct billing information. This 
process encompasses sending invoices to customers, pro- 
cessing their payments and performing payment collections. 
In addition, this process handles customer inquiries about 
bills, and is responsible to resolve billing problems to the 
customer's satisfaction. The aim is to provide a correct bill 
and, if there is a billing problem, resolve it quickly with 
appropriate status to the customer. An additional aim is to 
collect money due the service provider in a professional and 
customer supportive manner. 

FIG. 1H-1 is a flowchart illustrating an Invoice and 
Collections Process in accordance with a preferred embodi- 
ment. First, in step 192, customer account inquiries and 
customer payment information is received by the system. 
Next, in step 193, billing data, including discounts due to 
quality of service violations and rebates due to service level 
agreement violations, is collected and processed. Thereafter, 
in step 194, customer account invoices are created for 
distribution based on the customer payment information and 
the billing data. 

Mediation and activity tracking are provided by the event 
logger and event manager. The event logger and event 
manager feed the rating and billing information for degraded 
service using the personally customized rules database. 
Utilizing an expert system for the tailored capabilities of 
each customer, the event driver, collector and manager 
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analyze notification events generated by the system. When a 
notification event is received the system analyzes the event 
and uses it to identify the customer. The notification event is 
also used to credit the customer if they experience a non- 
impacting event that breaches the customer's contract. In 
addition to the system itself generating the notification 
event, the customer is also able to notify the provider 
directly should such an event occur. 

FIG. 2 A is a flowchart illustrating media communication 
over the hybrid network of the present invention. When a 
customer initiates a use of the hybrid network, the hybrid 
network, in a first step 220, transfers the media over the 
network using IP information to route it to the appropriate 
destination. The media transferred over the network may be 
telephony data, image data, or any other data capable of 
packet switched transmission. 

In a second step 222, events are generated based on the 
quality of service of the media transfer. As discussed above 
with reference to FIG. ID and FIG. IE, these events include 
performance notifications due to SLA violations, and cus- 
tomer generated events from the Customer Interface Man- 
agement Process 132. 

In a third step 224, the events generated in step 222 are 
utilized to generate a bill for the customer. In addition to 
normal billing for service provided via the hybrid network, 
the bill is modified based on events generated during the 
media transfer. For example, events representing SLA vio- 
lations are used to credit customers. As discussed above with 
reference to FIGS. IF, 1G, and 1H, the Problem Handling 
Process 138 is responsible for receiving service complaints 
and other service-affecting problems. Together with the 
Network Data Management 130, the Problem Handling 
Process feeds data to the Discounting Process 140. The 
Discounting Process 140 applies the correct rating rules on 
a customer-by-customer basis, and applies discounts for 
events, such as outages and other SLA violations. Finally, 
the Invoice and Collections Process 142, utilizes the infor- 
mation from the Discounting Process 140 to create customer 
billing information. 

To better understand the invention, it is useful to describe 
some additional terminology relating to a telecommunica- 
tion network. A telephone call comes into a switch on a 
transmission line referred to as the originating port, or trunk. 
The originating port is one of many transmission lines 
coming into the switch from the same location of origin. 
This group of ports is the originating trunk group. After 
processing an incoming call, the switch transmits the call to 
a destination location, which may be another switch, a local 
exchange carrier, or a private branch exchange. The call is 
transmitted over a transmission line referred to as the 
terminating port, or trunk. Similar to the originating port, the 
terminating port is one of a group of ports going from the 
switch to the same destination. This group of ports is the 
terminating trunk group. 

Contemporary telecommunication networks provide cus- 
tomers with the capability of using the general public 
network as well as the capability of defining a custom virtual 
network (VNet). With a VNet, a customer defines a private 
dialing plan, including plan telephone numbers. A VNet 
customer is not limited to the default telephone numbers 
allocated to a public telecommunication system dedicated to 
a specific geographic region, but can define custom tele- 
phone numbers. 

Upon processing a telephone call, a switch must generate 
a call record large enough to contain all of the needed 
information on a call. The call record, however, must not be 
so large that the typical call results in the majority of the 
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record fields in the call record to be unused. In such a case, 
storing such call records results in large amounts of wasted 
storage, and transmitting such a call record causes unnec- 
essary transmissions. 

s One solution for creating and processing call records is to 
implement a fixed length call record format, such as a 
32-word call record. A word is two (2) bytes, or sixteen (16) 
bits. A fixed length record format, however, cannot expand 
when new call features are implemented. More importantly, 

10 fixed call record formats cannot handle expanded data fields 
as the telecommunications network becomes more complex 
with new features and telephone numbers. 

Contemporary fixed length record formats include time 
point fields recording local time in three (3) second incre- 

15 ments where local switch time represents the time of day at 
a switch. The timepoint fields are used by the network 
switches, billing center, and other network subsystems. Each 
subsystem, however, may require the time period for a 
different use and in a different format, such as in an epoch 

20 time format. Epoch time is the number of one (1) second 
increments since a particular date and time in history. For 
example, the billing center requires epoch time for its billing 
records whereas switch reports and error logs require local 
switch time. 

25 A problem also arises when using only local switch time 
in that there is no accommodation for time changes due to 
daylight savings time. In addition, each subsystem may 
require a finer granularity of precision than the current three 
(3) second increments. By providing only local switch time 

30 at three (3) second increments, the switches have passed the 
burden of translating the time into a usable format to the 
network subsystems. The fixed record format cannot accom- 
modate the various time period requirements because it only 
contains the time periods in local switch time at a low level 

35 of precision. Because of its fixed nature, the fixed record 
format cannot expand to include different time formats, nor 
to include a finer granularity of precision, such as a one (1) 
second increment. 

Therefore, there is a need for switches of a telecommu- 

40 nications network to store call record information in a 
flexible and expandable format. There is a further need to 
provide time point fields with one (1) second granularity in 
a flexible format that easily and efficiently responds to 
daylight savings time and time zone changes. 

45 There is also a need to match all of the call records 
associated with a specific telephone call. For example, for 
proper billing and cost control, it is necessary for the billing 
center to match the originating switch's call record to the 
terminating switch's call record. Also, for troubleshooting 

50 and security purposes, it may be necessary to trace a specific 
telephone call through the network with ease in order to 
isolate problem areas. 

Therefore, there is a need for switches of a telecommu- 
nications network to uniquely identify each telephone call 

55 that traverses the network, thereby uniquely identifying all 
of the call records associated with a specific telephone call. 
An Embodiment 
Call Record Format 

An embodiment solves the problem of providing a flex- 
60 ible and expandable call record format by implementing 
both a small and a large call record format. In particular, the 
embodiment implements a default 32-word call record 
format, plus an expanded 64-word call record format. An 
embodiment uses a 32-word call record format for the 
65 typical telephone call, which comprises the majority of all 
telephone calls, and uses a 64-word call record format when 
additional information is needed regarding the call. This 
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implementation provides the flexibility needed to efficiently 
manage varying data requirements of a given call record. 
New call features can be developed and easily incorporated 
into the variable call record format of the present invention. 

Ibis embodiment also records timepoints in the epoch 
time format. The embodiment records the origination time of 
a call in epoch time format, and the remaining timepoints are 
offsets, or the number of seconds, from that origination time. 
This embodiment solves the problems associated with con- 
verting to and from daylight savings time because daylight 
savings time is a local time offset and does not affect the 
epoch time. Furthermore, the timepoints in epoch time 
format require less space in the call record than they do in 
local switch time format. 

The epoch time format may represent coordinated uni- 
versal time (UTC), as determined at Greenwich, England, 
which has a time zone of zero (0) local switch time, or any 
other time. Epoch time is only a format and does not dictate 
that UTC must be used. The billing time and the local switch 
time may be in UTC or local time, and the local switch time 
may not necessarily be the same time that is used for billing. 
Therefore, the switch must keep billing time and local 
switch time separate in order to prevent the problems that 
occur during daylight savings time changes. 

Network Call Identifier 

This embodiment solves the problem of uniquely identi- 
fying each telephone call and all of the call records associ- 
ated with a specific telephone call by providing a unique 
identifier to each call record. It generates a network call 
identifier (NCID) that is assigned to each call record at the 
point of call origination, that is, the originating switch 
generates an NCID for each telephone call. The NCID 
accompanies the associated telephone call through the tele- 
communications network to the termination point at the 
' terminating switch. Therefore, at any point of a telephone 
call in the network, the associated NCID identifies the point 
and time of origin of the telephone call. Each switch through 
which the telephone call passes records the NCID in the call 
record associated with the call. The NCID is small enough 
to fit in a 32-word call record, thereby reducing the data 
throughput and storage. The NCID provides the billing 
center and other network subsystems with the ability to 
match originating and terminating call records for a specific 
telephone call. 

This embodiment also provides the switch capability of 
discarding a received NCID and generating a new NCID. A 
switch discards a received NCID if the NCID format is 
invalid or unreliable, thereby ensuring a valid unique iden- 
tifier to be associated with each call going through the 
network. For instance, an NCID may be unreliable if gen- 
erated by third party switches in the telecommunications 
network. 

This embodiment relates to switches of a telecommuni- 
cation network that generate call records using a flexible and 
expandable record format. The call record formats include a 
small (preferably 32-word) and a large (preferably 64-word) 
expanded format. It would be readily apparent to one skilled 
in the relevant art to implement a small and large record 
format of different sizes. 

The embodiment also relates to switches of a telecom- 
munication network that generate a unique NCID for each 
telephone call traversing the network. The NCID provides a 
mechanism for matching all of the call records associated 
with a specific telephone call. It would be readily apparent 
to one skilled in the relevant art to implement a call record 
identifier of a different format. 

The chosen embodiment is computer software executing 
within a computer system. FIG. 2B shows an exemplary 
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computer system. The computer system 202 includes one or 
more processors, such as a processor 204. The processor 204 
is connected to a communication bus 206. 

The computer system 202 also includes a main memory 
208, preferably random access memory (RAM), and a 
secondary memory 210, The secondary memory 210 
includes, for example, a hard disk drive 212 and/or a 
removable storage drive 214, representing a floppy disk 
drive, a magnetic tape drive, a compact disk drive, etc. The 
removable storage drive 214 reads from and/or writes to a 
removable storage unit 216 in a well known manner. 

Removable storage unit 216, also called a program stor- 
age device or a computer program product, represents a 
floppy disk, magnetic tape, compact disk, etc. The remov- 
able storage unit 216 includes a computer usable storage 
medium having therein stored computer software and/or 
data. 

Computer programs (also called computer control logic) 
are stored in main memory 208 and/or the secondary 
memory 210. Such computer programs, when executed, 
enable the computer system 202 to perform the functions of 
the present invention as discussed herein. In particular, the . 
computer programs, when executed, enable the processor 
204 to perform the functions of the present invention. 
Accordingly, such computer programs represent controllers 
of the computer system 202, 

Another embodiment is directed to a computer program 
product comprising a computer readable medium having 
control logic (computer software) stored therein. The control 
logic, when executed by the processor 204, causes the 
processor 204 to perform the functions as described herein. 

Another embodiment is implemented primarily in hard- 
ware using, for example, a hardware state machine. Imple- 
mentation of the hardware state machine so as to perform the 
functions described herein will be apparent to persons 
skilled in the relevant arts. 

Call Record Format 

This embodiment provides the switches of a telecommu- 
nication network with nine (9) different record formats. 
These records include: Call Detail Record (CDR), Expanded 
Call Detail Record (ECDR), Private Network Record 
(PNR), Expanded Private Network Record (EPNR), Opera- 
tor Service Record (OSR), Expanded Operator Service 
Record (EOSR), Private Operator Service Record (POSR), 
Expanded Private Operator Service Record (EPOSR), and 
Switch Event Record (SER). Each record is 32 words in 
length, and the expanded version of each record is 64 words 
in length. 

Example embodiments of the nine (9) call record formats 
discussed herein are further described in FIGS. 1-5. The 
embodiments of the call records of the present invention 
comprise both 32-word and 64-word call record formats. It 
would be apparent to one_ skilled in _the relevant art to 
develop alternative embodiments for call records compris- 
ing a different number of words and different field defini- 
tions. Table 301 of the Appendix contains an example 
embodiment of the CDR and PNR call record formats. FIG. 
3 shows a graphical representation of the CDR and PNR call 
record formats. Table 302 of the Appendix contains an 
example embodiment of the ECDR and EPNR call record 
formats. FIGS. 4 A and 4B show a graphical representation 
of the ECDR and EPNR call record formats. Table 303 of the 
Appendix contains an example embodiment of the OSR and 
POSR call record formats. FIG. 5 shows a graphical repre- 
sentation of the OSR and POSR call record format. Table 
304 of the Appendix contains an example embodiment of the 
EOSR and EPOSR call record formats. FIGS. 6(A) and 6(B) 
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show a graphical representation of the EOSR and EPOSR 
call record formats. Table 305 of the Appendix contains an 
embodiment of the SER record format. FIG. 7 shows a 
graphical representation of the SER record format. 

The CDR and PNR, and thereby the ECDR and EPNR, s 
are standard call record formats and contain information 
regarding a typical telephone call as it passes through a 
switch. The CDR is used for a non-VNET customer, whereas 
the PNR is used for a VNET customer and is generated at 
switches that originate VNET calls. The fields of these two 
records are identical except for some field-specific informa- 
tion described below. 

The OSR and POSR, and thereby the EOSR and EPOSR, 
contain information regarding a telephone call requiring 
operator assistance and are generated at switches or systems 
actually equipped with operator positions. A switch com- 15 
pletes an OSR for a non-VNET customer and completes a 
POSR for a private VNET customer. These records are only 
generated at switches or systems that have the capability of 
performing operator services or network audio response 
system (NARS) functions. The formats of the two (2) 20 
records are identical except for some field-specific informa- 
tion described below. A SER is reserved for special events 
such as the passage of each hour mark, time changes, system 
recoveries, and at the end of a billing block. The SER record 
format is also described in more detail below. is 

FIGS. 8(A) and 8(B) collectively illustrate the logic that 
a switch uses to determine when to use an expanded version 
of a record format. A call 202 comes into a switch 106-110 
(called the current switch for reference purposes; the current 
switch is the switch that is currently processing the call), at 30 
which time that switch 106-110 determines what call record 
and what call record format (small/default or large/ 
expanded) to use for the call's 802 call record. In this regard, 
the switch 106-110 makes nine (9) checks for each call 802 
that it receives. The switch 106-110 uses an expanded 35 
record for a call 802 that passes any check as well as for a 
call 802 that passes any combination of checks. 

The first check 804 determines if the call is involved in a 
direct termination overflow (DTO) at the current switch 
106-110. For example, a DTO occurs when a customer 40 
makes a telephone call 802 to an 800 number and the 
original destination of the 800 number is busy. If the original 
destination is busy, the switch overflows the telephone call 
802 to a new destination. In this case, the switch must record 
the originally attempted destination, the final destination of 45 
the telephone call 802, and the number of times of overflow. 
Therefore, if the call 802 is involved in a DTO, the switch 
106-110 must complete an expanded record (ECDR, EPNR, 
EOSR, EPOSR) 816. 

The second check 806 made on a call 802 by a switch 50 
106-110 determines if the calling location of the call 802 is 
greater than ten (10) digits. The calling location is the 
telephone number of the location from where the call 802 
originated. Such an example is an international call which 
comprises at least eleven (11) digits. If the calling location 55 
is greater than ten (10) digits, the switch records the tele- 
phone number of the calling location in an expanded record 
(ECDR, EPNR, EOSR, EPOSR) 816. 

A switch 106-110 makes a third check 808 on a call 802 
to determine if the destination address is greater than sev- 60 
enteen (17) digits. The destination address is the number of 
the called location and may be a telephone number or trunk 
group. If the destination is greater than seventeen (17) digits, 
the switch records the destination in an expanded record 
(ECDR, EPNR, EOSR, EPOSR) 816. 65 

A switch 106-110 makes a fourth check 810 on a call 802 
to determine if the pre-translated digits field is used with an 



518 

30 

operated assisted'service call. The pre-translated digits are 
the numbers of the call 802 as dialed by a caller if the call 
202 must be translated to another number within the net- 
work. Therefore, when a caller uses an operator service, the 
switch 106-110 records the dialed numbers in expanded 
record (EOSR, EPOSR) 816. 

In a fifth check 812 on a call 802, a switch 106-110 
determines if the pre-translated digits of a call 802 as dialed 
by a caller without operator assistance has more than ten 
(10) digits. If there are more than ten (10) pre-translated 
digits, the switch 106-110 records the dialed numbers in 
expanded record (ECDR, EPNR) 816. 

In a sixth check 814 on a call 802, a switch 106-110 
determines if more than twenty- two (22) digits, including 
supplemental data, are recorded in the Authorization Code 
field of the call record. The Authorization Code field indi- 
cates a party who gets billed for the call, such as the calling 
location or a credit card call. If the data entry requires more 
than twenty-two (22) digits, the switch 106-110 records the 
billing information in an expanded record (ECDR, EPNR, 
EOSR, EPOSR) 816. 

In a seventh check 820 on a call 802, a switch 106-110 
determines if the call 802 is a wideband call A wideband call 
is one that requires multiple transmission lines, or channels. 
For example, a typical video call requires six (6) transmis- 
sion channels: one (1) for voice and five (5) for the video 
transmission. The more transmission channels used during a 
wideband call results in a better quality of reception. Con- 
temporary telecommunication systems currently provide up 
to twenty-four (24) channels. Therefore, to indicate which, 
and how many, of the twenty-four channels is used during a 
wideband call, the switch records the channel information in 
an expanded record (ECDR, EPNR) 828. 

In an eighth check 822 on a call 802, a switch 106-110 
determines if the time and charges feature was used by an 
operator. The time and charges feature is typically used in a 
hotel scenario when a hotel guest makes a telephone call 
using the operator's assistance and charges the call 802 to 
her room. After the call 802 has completed, the operator 
informs the hotel guest of the charge, or cost, of the call 802. 
If the time and charges feature was used with a call 802, the 
switch 106-110 records the hotel guest's name and room 
number in an expanded record (EOSR, EPOSR) 832. 

The ninth, and final, check 824 made on a call 802 by a 
switch 106-110 determines if the call 802 is an enhanced 
voice service/network audio response system (EVS/NARS) 
call. An EVS/NARS is an audio menu system in which a 
customer makes selections in response to an automated 
menu via her telephone key pad. Such a system includes a 
NARS switch on which the audio menu system resides. 
Therefore, during an EVS/NARS call 802, the NARS switch 
106-110 records the customer's menu selections in an 
expanded record (EOSR, EPOSR) 832. 

If none of the checks 804-824 return a positive result, 
then the switch 106-110 uses the default record format 
(OSR, POSR) 830. Once the checks have been made on a 
call, a switch generates and completes the appropriate call 
record. Call record data is recorded in binary and Telephone 
Binary Coded Decimal (TBCD) format. TBCD format is 
illustrated below: 

0000=TBCD-Null 

0001 -digit 1 

0010=digit 2 

0011=digit 3 

0100- digit 4 

0101 - digit 5 
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OllO^digit 6 
0111=digit 7 
1000=digit 8 
1001=digit 9 
1010=digit 0 

lOlUspecial digit 1 (DTMF digit A) 
1100=speckl digit 2 (DTMF digit B) 
llOlospecial digit 3 (DTMF digit C) 
1110=special digit 4 (DTMF digit D) 
llll=special digit 5 (Not Used) 

All TBCD digit fields must be filled with TBCD-Null, or 
zero, prior to data being recorded. Where applicable, dialed 
digit formats conform to these conventions: 

N=digits 2-9 

X=digits 0-9 

Y=digits 2-8 

Thus, if the specification for a call record field contains a 
N, the valid field values are the digits 2-9. 

Each call record, except SER, contains call specific time- 
point fields. The timepoint fields are recorded in epoch time 
format. Epoch time is the number of one second increments 
from a particular date/time in history. The embodiment of 
the present invention uses a date/time of midnight (00:00 am 
UTC) on Jan. 1, 1976, but this serves as an example and is 
not a limitation. It would be readily apparent to one skilled 
in the relevant art to implement an epoch time based on 
another date/time. In the records, Timepoint 1 represents the 
epoch time that is the origination time of the call 802. The 
other timepoint stored in the records are the number of 
seconds after Timepoint 1, that is, they are offsets from 
Timepoint 1 that a particular timepoint occurred. All of the 
timepoint fields must be filled in with "0 V prior to any data 
being recorded. Therefore, if a timepoint occurs, its count is 
one (1) or greater. Additionally, timepoint counters, not 
including Timepoint 1, do not rollover their counts, but stay 
at the maximum count if the time exceeds the limits. 

The switch clock reflects local switch time and is used for 
all times except billing. Billing information is recorded in 
epoch time, which in this embodiment is UTC. The Time 
offset is a number reflecting the switch time relative to the 
UTC, that is, the offset due to time zones and, if appropriate, 
daylight savings time changes. There are three factors to 
consider when evaluating time change relative to UTC. 
First, there are time zones on both sides of UTC, and 
therefore there may be both negative and positive offsets. 
Second, the time zone offsets count down from zero (in 
Greenwich, England) in an Eastward direction until the 
International Dateline is reached. At the Dateline, the date 
changes to the next day, such that the offset becomes positive 
and starts counting down until the zero offset is reached 
again at Greenwich. Third, there are many areas of the world 
that have time zones that are not in exact one-hour incre- 
ments. For example, Australia has one time zone that has a 
thirty (30) minute difference from the two time zones on 
either side of it, and Northern India has a time zone that is 
fifteen (15) minutes after the one next to it. Therefore, the 
Time Offset of the call records must account for variations 
in both negative and positive offsets in fifteen (15) minute 
increments. The embodiment of the present invention sat- 
isfies this requirement by providing a Time Offset repre- 
senting either positive or negative one minute increments. 

There are two formulas used to convert local switch time 
to epoch time and back. 

i) Epoch Time+(Sign Bit*Time Offset)=Local Switch Time 

ii) Local Switch Time-(Sign Bit*Time Offset)-Epoch Time 
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The switch records the Time Offset in the SER using a 
value where one (1) equals one (1) minute, and computes the 
Tune Offset in seconds and adds this value to each local 
Timepoint 1 before the call record is recorded. For example, 

5 Central Standard Time is six (6) hours before UTC. In this 
case, the Sign Bit indicates "1" for negative offset and the 
Time Offset value recorded in the SER would be 360 (6 
hours* 60 minutes/hour=360 minutes). See FIG. 5 for more 
details on the SER record format. When recording Time- 

10 point 1 in the call record, the switch multiplies the Time 
Offset by 60, because there is 60 seconds in each 1 minute 
increment, and determines whether the offset is positive or 
negative by checking the Sign Bit. This example results in 
a value of -21,600 (-1*360 minutes* 60 seconds/minute=- 

15 21,600 seconds). Using equation (ii) from above, if the local 
switch time were midnight, the corresponding epoch time 
might be, for example, 1,200,000,000. Subtracting the Time 
Offset of -21,600 results in a corrected epoch time of 
1,200,021,600 seconds, which is the epoch time for 6 hours 

20 after midnight on the next day in epoch time. This embodi- 
ment works equally as well in switches that are positioned 
on the East side of Greenwich where the Time Offset has a 
positive value. 

Two commands are used when changing time. First, FIG. 

25 9 illustrates the control flow of the Change Time command 
900, which changes the Local Switch Time and the Time 
Offset. In FIG. 9, after a switch operator enters the Change 
Time command, the switch enters step 902 and prompts the 
switch operator for the Local Switch Time and Time Offset 

30 from UTC. In step 902 the switch operator enters a new 
Local Switch Time and Time Offset. Continuing to step 904, 
the new time and Time Offset are displayed back to the 
switch operator. Continuing to step 906, the switch operator 
must verify the entered time and Tune Offset before the 

35 actual time and offset are changed on the switch. If in step 
906 the switch operator verifies the changes, the switch 
proceeds to step 908 and generates a SER with an Event 
Qualifier equal to two which identifies that the change was 
made to the Local Switch Time and Time Offset of the 

40 switch. The billing center uses the SER for its bill process- 
ing. The switch proceeds to step 910 and exits the command. 
Referring back to step 906, if the switch operator does not 
verify the changes, the switch proceeds to step 910 and exits 
the command without updating the Local Switch Time and 

45 Time Offset. For more information on SER, see FIG. 5. 
FIG. 10 illustrates the control flow for the Change Day- 
light Savings Time command 1000 which is the second 
command for changing time. In FIG. 10, after a switch 
operator enters the Change Daylight Savings Time 

50 command, the switch enters step 1002 and prompts the 
switch operator to select either a Forward or Backward time 
change. Continuing to step 1004, the switch operator makes 
a selection. In step 1004, if the switch operator selects the 
Forward option, the switch enters step 1006. In step 1006, 

55 the switch sets the Local Switch Time forward one hour and 
adds one hour (count of 60) to the Time Offset. The switch 
then proceeds to step 1010. 

Referring back to step 1004, if the switch operator selects 
the Backward option, the switch sets the Local Switch Time 

60 back one hour and subtract one hour (count of 60) from the 
Time Offset. The switch then proceeds to step 1010. 

In step 1010, the switch operator must verify the forward 
or backward option and the new Local Switch Time and 
Time Offset before the actual time change takes place. If in 

65 step 1010, the switch operator verifies the new time and 
Time Offset, the switch proceeds to step 1012 and generates 
a SER with an Event Qualifier equal to nine which changes 
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the Local Switch Time and Time Offset of the switch. The 
switch proceeds to step 1014 and exits the command. 
Referring back to step 1010, if the switch operator does not 
verify the changes, the switch proceeds to step 1014 and 
exits the command without updating the Local Switch Time 5 
and Time Offset. 

After the successful completion of a Change Daylight 
Savings Time Command, the billing records are affected by 
the new Time Offset. This embodiment allows the epoch 
time, used as the billing time, to increment normally through 10 
the daylight savings time change procedure, and not to be 
affected by the change of Local Switch Time and Time 
Offset. 

Network Call Identifier 

An embodiment provides a unique NCID that is assigned 15 
to each telephone call that traverses through the telecom- 
munications network. Thus, the NCID is a discrete identifier 
among all network calls. The NCID is transported and 
recorded at each switch that is involved with the telephone 
call. 20 

The originating switch of a telephone call generates the 
NCID. The chosen embodiment of the NCID of the present 
invention is an eighty-two (82) bit identifier that is com- 
prised of the following sub fields: 

i) Originating Switch ID (14 bits): This field represents the 25 
NCS Switch ID as defined in the Office Engineering table 

at each switch. The SER call record, however, contains an 
alpha numeric representation of the Switch ID. Thus, a 
switch uses the alphanumeric Switch ID as an index into 
a database for retrieving the corresponding NCS Switch 30 
ID. 

ii) Originating Trunk Group (14 bits): This field represents 
the originating trunk group as defined in the 32/64-word 
call record format described above. 

iii) Originating Port Number (19 bits): This field represents 35 
the originating port number as defined in the 32/64-word 
call record format described above. 

iv) Timepoint 1 (32 bits): This field represents the Timepoint 
1 value as defined in the 32/64-word call record format 
described above. 40 

v) Sequence Number (3 bits): This field represents the 
number of calls which have occurred on the same port 
number with the same Timepoint 1 (second) value. The 
first telephone call will have a sequence number set to '0/ 
This value increases incrementally for each successive 45 
call which originates on the same port number with the 
same Timepoint 1 value. 

It would be readily apparent to one skilled in the relevant 
art to create an NCID of a different format. Each switch 
records the NCID in either the 32 or 64-word call record 50 
format. Regarding the 32-word call record format, interme- 
diate and terminating switches will record the NCID in the 
AuthCode field of the 32-wprd call record if the AuthCode 
filed is not used to record other information. In this case, the 
Originating Switch ID is the NCS Switch ID, not the 55 
alphanumeric Switch ID as recorded in the SER call record. 
If the AuthCode is used for other information, the interme- 
diate and terminating switches record the NCID in the 
64-word call record format. In contrast, originating switches 
do not use the AuthCode field when storing an NCID in a 60 
32-word call record. Originating-switches record the sub- 
fields of the NCID in the corresponding separate fields of the 
32-word call record. That is, the Originating Switch ID is 
stored as an alphanumeric Switch ID in the Switch ID field 
of the SER call record; the Originating Trunk Group is 65 
stored in the Originating Trunk Group field of the 32-word 
call record; the Originating Port Number is stored in the 
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Originating Port field of the 32-word call record; the Time- 
point 1 is stored in the Timepoint 1 field of the 32-word call 
record; the Sequence Number is stored in the NCID 
Sequence Number field of the 32-word call record. The 
32-word call record also includes an NCID Location 
(NCIDLOC) field to identify when the NCID is recorded in 
the AuthCode field of the call record. If the NCID Location 
field contains a '1/ then the AuthCode field contains the 
NCID. If the NQD Location field contains a '0,' then the 
NCID is stored in its separate sub-fields in the call record. 
Only intermediate and terminating switches set the NCID 
Location field to a i V because originating switches store the 
NCID in the separate fields of the 32-word call record. 

Regarding the 64-word call record format, the expanded 
call record includes a separate field, call the NCID field, to 
store the 82 bits of the NCID. This call record is handled the 
same regardless of whether an originating, intermediate, or 
terminating switch stores the NCID. In the 64-word call 
record format, the Originating Switch ID is the NCS Switch 
ID, not the alphanumeric Switch ID as recorded in the SER 
call record. 

FIG. 11 illustrates the control flow of the Network Call 
Identifier switch call processing. A call 202 comes into a 
switch 106-110 (called the current switch for reference 
purposes; the current switch is the switch that is currently 
processing the call) at step 1104. In step 1104, the current 
switch receives the call 202 and proceeds to step 1106. In 
step 1106, the current switch accesses a local database and 
gets the trunk group parameters associated with the origi- 
nating trunk group of the call 202. After getting the 
parameters, the current switch proceeds to step 1108. In step 
1108, the current switch determines if it received an NCID 
with the call 202. If the current switch did not receive an 
NCID with the call 202, the switch continues to step 1112. 

In step 1112, the switch analyzes the originating trunk 
group parameters to determine the originating trunk group 
type. If the originating trunk group type is an InterMachine 
Trunk (IMT) or a release link trunk (RLT), then the switch 
proceeds to step 1116. An IMT is a trunk connecting two 
normal telecommunication switches, whereas a RLT is a 
trunk connecting an intelligent services network (ISN) plat- 
form to- a normal telecommunication switch: When the — 
current switch reaches step 1116, the current switch knows 
that it is not an originating switch and that it has not received 
an NQD. In step 1116, the current switch analyzes the 
originating trunk group parameters to determine whether it 
is authorized to create an NCID for the call 202. In step 1116, 
if the current switch is not authorized to create an NCID for 
the call 202, the current switch proceeds to step 1118, When 
in step 1118, the current switch knows that it is not an 
originating switch, it did not receive an NCID for the call 
202, but is not authorized to generate an NCID. Therefore, 
in step 1118, the current switch writes the call record 
associated with the call 202 to the local switch. database and 
proceeds to step 1120. In step 1120, the current switch 
transports the call 202 out through the network with its 
associated NCID. Step 1120 is described below in more 
detail. 

Referring again to step 1116, if the current switch is 
authorized to create an NCID for the call 202, the current 
switch proceeds to step 1114. In step 1114, the current switch 
generates a new NCID for the call 202 before continuing to 
step 1136. In step 1136, the current switch writes the call 
record, including the NCID, associated with the call 202 to 
the local switch database and proceeds to step 1120. In step 
1120, the current switch transports the call 202 out through 
the network with its associated NCID. Step 1120 is 
described below in more detail. 
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Referring again to step 1112, if the current switch deter- 
mines that the originating trunk group type is not an IMT or 
RLT, the current switch proceeds to step 1114. When reach- 
ing step 1114, the current switch knows that it is an origi- 
nating switch and, therefore, must generate a NCID for the 
call 202. Step 1114 is described below in more detail. After 
generating a NCID in step 1114, the current switch proceeds 
to step 1136 to write the call record, including the NCTD, 
associated with the call 202 to the local database. After 
writing the call record, the current switch proceeds to step 
1120 to transport the call out through the network with its 
associated NCID. Step 1120 is also described below in more 
detail 

Referring again to step 1108, if the current switch deter- 
mines that it received an NCID with the call 202, the current 
switch proceeds to step 1110. In step 1110, the current switch 
processes the received NCID. In step 1U0, there are two 
possible results. First, the current switch may decide not to 
keep the received NCID thereby proceeding from step 1110 
to step 1114 to generate a new NCID. Step 1110 is described 
below in more detail. In step 1114, the current switch may 
generate a new NCID for the call 202 before continuing to 
step 1136. Step 1114 is also described below in more detail. 
In step 1136, the current switch writes the call record 
associated with the call 202 to the local database. The 
current switch then proceeds to step 1120 and transports the 
call 202 out through the network with its associated NCID. 
Step 1120 is also described below in more detail. 

Referring again to step 1110, the current switch may 
decide to keep the received NCID thereby proceeding from 
step 1110 to step 1115. In step 1115, the current switch adds 
the received NQD to the call record associated with the call 
202. Steps 1110 and 1115 are described below in more detail. 
After step 1115, the current switch continues to step 1136 
where it writes the call record associated with the call 202 
to the local database. The current switch then proceeds to 
step 1120 and transports the call 202 out through the network 
with its associated NCID. Step 1120 is also described below 
in more detail. 

FIG. 12 illustrates the control logic for step 1110 which 
processes a received NCID. The current switch enters step 
1202 of step 1110 when it determines that an NQD was 
received with the call 202. In step 1202, the current switch 
analyzes the originating trunk group parameters to deter- 
mine the originating trunk group type. If the originating 
trunk group type is an IMT or RLT, then the current switch 
proceeds to step 1212. When in step 1212, the current switch 
knows that it is not an originating switch and that it received 
an NCID for the call 202. Therefore, in step 1212, the 
current switch keeps the received NCID and exits step 1110, 
thereby continuing to step 1115 in FIG. 11, after which the 
current switch will store the received NCID in the call record 
and transport the call. 

Referring again to step 1202, if the originating trunk 
group type is not an IMT or RLT, the current switch proceeds 
to step 1204. In step 1204, the current switch determines if 
the originating trunk group type is an Integrated Services 
User Parts Direct Access Line (ISUP DAL) or an Integrated 
Services Digital Network Primary Rate Interface (ISDN 
PRI). ISUP is a signaling protocol which allows information 
to be sent from switch to switch as information parameters. 
An ISUP DAL is a trunk group that primarily is shared by 
multiple customers of the network, but can also be dedicated 
to a single network customer. In contrast, an ISDN PRI is a 
trunk group that primarily is dedicated to a single network 
customer, but can also be shared by multiple network 
customers. A network customer is an entity that leases 
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network resources. In step 1204, if the current switch 
determines that the trunk group type is not an ISUP DAL or 
ISDN PRI, the current switch proceeds to step 1206. When 
in step 1206, the current switch knows that it received an 

5 NCID that was not generated by a switch that is part of the 
telecommunication network or by a switch that is a customer 
of the network. Therefore, in step 1206, the current switch 
discards the received NCID because it is an unreliable 
NCID. From step 1206, the current switch exits step 1110, 

10 thereby continuing to step 1114 in FIG. 11 where the current 
switch will create a new NQD and transport that NCID with 
the call 202. 

Referring back to step 1204, if the current switch deter- 
mines that the originating trunk group type is an ISUP DAL 

15 or ISDN PRI, the current switch continues to step 1208. 
When in step 1208, the current switch knows that it received 
an NCID from a customer trunk group. Therefore, the 
current switch analyzes the originating trunk group param- 
eters to determine whether it is authorized to create a new 

20 NCID for the call 202. The current switch may be authorized 
to create a new NCID and overwrite the NCID provided by 
the customer to ensure that a valid NCID corresponds to the 
call 202 and is sent through the network. In step 1208, if the 
current switch is not authorized to create a new NCID for the 

25 call 202, the current switch proceeds to step 1210. In step 
1210, the current switch checks the validity of the received 
NCID, for example, the NCID length. If the received NCID 
is invalid, the current switch proceeds to step 1206. In step 
1206, the current switch discards the invalid NCID. From 

30 step 1206, the current switch exits step 1110, thereby con- 
tinuing to step 1114 in FIG. U where the current switch will 
create a new NQD and transport that NCID with the call 
202. Referring again to step 1210, if the current switch 
determines that the received NCID is valid, the current 

35 switch proceeds to step 1212, In step 1212 the current switch 
keeps the received NCID and exits step 1110, thereby 
continuing to step 1115 in FIG. 11 where the current switch 
will store the received NCID in the call record and transport 
the call. 

40 FIG. 13A illustrates the control logic for step 1114 which 
generates an NCID. The current switch enters step 1302 
when an NCID must be created. In step 1302, the current 
switch will calculate a sequence number. The sequence 
number represents the number of calls which have occurred 

45 on the same port number with the same Timepoint 1 value. 
The first call has a sequence number value of '0/ after which 
the sequence number will increase incrementally for each 
successive call that originates n the same port number with 
the same Timepoint 1 value. After creating the sequence 

50 number in step 1302, the current switch proceeds to step 
1304. In step 1304, the current switch creates a call record 
for the ca!1202, including in it the call's 202 newly created 
NCID. After the call record has been created, the current 
switch exits step 1114 and proceeds to step 1136 in FIG. U 

55 where the current switch writes the call record to the local 
switch database. 

FIG. 13B illustrates the control logic for step 1U5 which 
adds a received NCID to the call record associated with the 
call 202. Upon entering step 1115, the current switch enters 

60 step 1306. When in step 1306, the current switch knows that 
it has received a valid NCID from an intermediate or 
terminating switch, or from a customer switch. In step 1306, 
the current switch determines if the AuthCode field of the 
32-word call record is available for storing the NCID. If the 

65 AuthCode field is available, the current switch proceeds to 
step 1310. In step 1310, the current switch stores the NQD 
in the AuthCode field of the 32-word call record. The current 
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switch must also set the NCID Location field to the value '1* 
which indicates that the NCID is stored in the AuthCode 
field. After step 1310, the current switch exits step 1115 and 
continues to step 1136 in FIG. 11 where the current switch 
writes the call record to the local switch database. 

Referring again to step 1306, if the AuthCode field is not 
available in the 32-word call record, the current switch 
proceeds to step 1308. In step 1308, the curreDt switch stores 
the NCID in the NCID field of the 64-word call record. After 
step 1308, the current switch exits step 1115 and continues 
to step 1136 in FIG. 11 where the current switch writes the 
call record to the local switch database. 

FIG. 14 illustrates the control logic for step 1120 which 
transports the call from the current switch. There are two 
entry points for this control logic: steps 1402 and 1412. 
Upon entering step 1402 from step 1136 on FIG. 11, the 
current switch knows that it has created an NCID or has 
received a valid NCID. In step 1402, the current switch 
accesses a local database and gets the trunk group param- 
eters associated with the terminating trunk group for trans- 
porting the call 202. After getting the parameters, the current 
switch proceeds to step 1404. In step 1404, the current 
switch determines the terminating trunk group type. If the 
terminating trunk is an ISUP trunk, the current switch 
proceeds to step 1408. In step 1408, the current switch 
analyzes the parameters associated with the ISUP trunk type 
to determine whether or not to deliver the NCID to the next 
switch. If the current switch is authorized to deliver the 
NCID, the current switch proceeds to step 1416. In step 
1416, the current switch transports the call to the next switch 
along with a SS7 initial address message (IAM). The NCID 
is transported as part of the generic digits parameter of the 
IAM. The IAM contains setup information for the next 
switch which prepares the next switch to lo accept and 
complete the call 202. The format of the generic digits 
parameter is shown below in Table 306: 

TABLE 306 

Generic Digits Parameter: 
Code: 11000001 
Type: 0__ 

Byte #, Bit # Description 



byte 1, bits 0-4 



byte 1, bits 5-7 



byte 2, bits 0-7 
byte 3, bits 0-5 
byte 3, bits 6-7 
byte 4, bits 0-7 
byte 5, bits 0-3 
- byte 5,- bits 4-7 
byte 6, bits 0-7 
byte 7, bits 0-6 
byte 7, bit 7 
byte 8, bits 0-7 
byte 9, bits 0-7 
byte 10, bits 0-7 
byte 11, bits 0-7 
byte 12, bits 0-2 
byte 12, bite 3-7 



Type of Digits : Indicates the contents of the para- 
meter. This field has a binary value of '11011' to 
indicate that the parameter contains the NCID. 
Encoding Scheme : Indicates the format of the para- 
meter contents. This field has a binary value of '011' 
to indicate that the NCID is stored in the binary 
format. 

Originating Switch ID 
Originating Trunk Group 



Originating Port Number 

Not Used 
Timepoint 1 



NCID Sequence Number 
Not Used 



After transporting the call 202 and the IAM, the current 
switch proceeds to step 1418, thereby exiting the switch 
processing. Referring again to step 1408, if the current 
switch is not authorized to deliver the NCID to the next 
switch in an IAM message, the current switch proceeds to 
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step 1412. In step 1412, the current switch transports the call 
202 to the next switch under normal procedures which 
consists of sending an IAM message to the next switch 
without the NCID recorded as part of the generic digits 
parameter. After transporting the call 202, the current switch 
proceeds to step 1418, thereby exiting the switch processing. 

Referring again to step 1404, if the current switch deter- 
mines that the terminating trunk is not an ISUP, the current 
switch proceeds to step 1406. In step 1406, the current 
switch determines if the terminating trunk group is an ISDN 
trunk (the terminating trunk group is dedicated to one 
network customer). If the terminating trunk group is an 
ISDN, the current switch proceeds to step 1410. In step 
1410, the current switch analyzes the parameters associated 
with the ISDN trunk group type to determine whether or not 
to deliver the NCID to the next switch. If the current switch 
is authorized to deliver the NCID, the current switch pro- 
ceeds to step 1414. In step 1414, the current switch trans- 
ports the call to the next switch along with a setup message. 
The setup message contains setup information for the next 
switch which prepares the next switch to accept and com- 
plete the call 202. The NOD is transported as part of the 
locking shift codeset 6 parameter of the setup message. The 
format of the locking shift codeset 6 parameter is shown 
below in Table 307: 

TABLE 307 



Locking Shift Codeset 6 Parameter: 
Code: 11000001 
Type: 0 

Byte #, Bit # Description 



byte 1, bits 0-4 
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byte 1, bits 5-7 



byte 2, bits 0-7 
byte 3, bits 0-5 
byte 3, bits 6-7 
byte 4, bits 0-7 
byte 5, bits 0-3 
byte 5, bits 4-7 
byte 6, bits 0-7 
byte 7, bits 0-6 
byte 7, bit 7 
byte 8, bits 0-7 
byte 9, bits 0-7 
byte 10, bits 0-7 
byte 11, bits 0-7 
byte 12, bits 0-2 
byte 12, bits 3-7 



Type of Digits : Indicates the contents of the para- 
meter. This field has a binary value of '11011* 
to indicate that the parameter contains the NCID. 
Encoding Scheme : Indicates the format of the para- 
meter contents. This field has a binary value of '011' 
to indicate that the NCID is stored in the binary 
format. 

Originating Switch ID 
Originating Trunk Group 



Originating Port Number 

Not Used 
Timepoint 1 



NCID Sequence Number 
Not Used 



50 



After transporting the call 202 and the setup message, the 
current switch proceeds to step 1418, thereby exiting the 
switch processing. Referring, again to step 1410, if the. 
current switch determines that it does not have authority to 
deliver the NCID to the next switch in a setup message, the 
current switch proceeds to step 1412. In step 1412, the 
current switch transports the call 202 to the next switch 
under normal procedures which consists of sending a setup 
message to the next switch without the NCID recorded as 
part of the locking shift codeset 6 parameter. After trans- 
porting the call 202, the current switch proceeds to step 
1418, thereby exiting the switch processing. 

Referring again to step 1412, this step is also entered from 
step 1118 on FIG. 11 when the current switch did not receive 
an NCID, is an intermediate or terminating switch, and is not 
authorized to create an NCID. In this case, in step 1412, the 
current switch also transports the call 202 to the next switch 
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under normal procedures which consists of sending an IAM 
or setup message to the next switch without the NCID 
recorded as part of the parameter. After transporting the call 
202, the current switch proceeds to step 1418, thereby 
exiting the switch processing. 

A system and method for the switches of a telecommu- 
nications network to generate call records for telephone calls 
using a flexible and expandable record format. Upon receipt 
of a telephone call, a switch in the network analyzes the 
telephone call to determine whether the default call record is 
sufficiently large to store call record information pertaining 
to the telephone call, or whether the expanded call record 
must be used to store the call information pertaining to the 
telephone call. After determining which call record to use, 
the switch generates the default or expanded call record. The 
switch sends a billing block, comprised of completed call 
records, to a billing center upon filling an entire billing 
block. 

Introduction to a Callback Telephony System in 
Accordance with a Preferred Embodiment 

In today's telephony environment, a caller must contact 
an operator to initiate a conference call and/or have all 
parties dial a common number to connect into a conference 
call. This requires the cost of a human operator and the 
inconvenience of dialing a predefined number to be carried 
as overhead of each conference call. It also makes it very 
inefficient to schedule a conference call and assure that all 
parties are available to participate. It also requires a dedi- 
cated number for all the parties to access to facilitate the call. 

In accordance with a preferred embodiment, a callback 
system is facilitated by a caller accessing a display from a 
computer and filling out information describing the param- 
eters of a call. Information such as the date and time the call 
should be initiated, billing information, and telephone num- 
bers of parties to participate in the call could be captured. 
Then, based on the information entered, a central or distrib- 
uted computing facility with access to the hybrid network 
transmits e-mail in a note to each party required for the call 
copying the other parties to verify participation and calendar 
the event. The e-mail would include any particulars, such as 
the password associated with the call and time the call would 
be commenced. The necessary network facilities would also 
be reserved to assure the appropriate Quality of Service 
(QOS) would be available, and when the date and time 
requested arrived, the call is initiated by contacting each of 
the participants whether they be utilizing a telephone 
attached to a PSTN or a voice capable apparatus (such as a 
computer or intelligent television) attached to the hybrid 
network. At any time during scheduling, initiation or dura- 
tion of the call, any party could request operator assistance 
by selecting that service from the display associated with the 
call. Thus, a completely automated callback system is pro- 
vided for call setup and control. 

For callers that utilize the callback system on a regular 
basis a custom profile is provided as an extension to the 
users existing profile information. The custom profile allows 
a user to store frequent conference call participants infor- 
mation. The profile contains participant's telephone num- 
bers (which could be DDD, IDDD, IP Address or Cellular 
phone number), E-mail address, paging service, fax number, 
secretary phone number, location, time zone, working hours 
and other pertinent information that will be useful for 
initiating a call. Default profiles based on company or 
organization needs are also enabled and can be tailored to 
meet the needs of a particular user based on more global 
information. 
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Billing information would also be provided online. A user 
could enter a pre-arranged billing number or the ability to 
bill to a credit card or telephone number. If billing to a 
telephone number, the system treats the call like a collect or 
5 third party call to verify billing. 

If profile information were predefined for a particular call 
scenario, then another option would allow an immediate 
connection of a conference call or single call at the press of 
a button, much as speed dialing is performed today except 
10 that more than one caller could be joined without interven- 
tion of the calling party, Internet callers are supported and an 
operator can be joined as required. 

Before describing this aspect of the present invention, a 
description of internet environment is presented. 
15 Internet 

The Internet is a method of interconnecting physical 
networks and a set of conventions for using networks that 
allow the computers they reach to interact. Physically, the 
Internet is a huge, global network spanning over 92 coun- 

20 tries and comprising 59,000 academic, commercial, 
government, and military networks, according to the Gov- 
ernment Accounting Office (GAO), with these numbers 
expected to double each year. Furthermore, there are about 
10 million host computers, 50 million users, and 76,000 

25 World-Wide Web servers connected to the Internet. The 
backbone of the Internet consists of a series of high-speed 
communication links between major supercomputer sites 
and educational and research institutions within the U.S. and 
throughout the world. 

30 Protocols govern the behavior along the Internet back- 
bone and thus set down the key rules for data communica- 
tion. Transmission Control Protocol/Internet Protocol (TCP/ 
IP) has an open nature and is available to everyone, meaning 
that it attempts to create a network protocol system that is 

35 independent of computer or network operating system and 
architectural differences. As such, TCP/IP protocols are 
publicly available in standards documents, particularly in 
Requests for Comments (RFCs). A requirement for Internet 
connection is TCP/IP, which consists of a large set of data 

40 communications protocols, two of which are the Transmis- 
sion Control Protocol and the Internet Protocol. 

The International Telecommunication Union- 
Telecommunication Standardization Sector ("ITU-T") has 
established numerous standards governing protocols and 

45 line encoding for telecommunication devices. Because many 
of these standards are referenced throughout this document, 
summaries of the relevant standards are listed below for 
reference. 

ITU G.711 Recommendation for Pulse Code Modulation of 
50 3 kHz Audio Channels. 

ITU G.722 Recommendation for 7 kHz Audio Coding 

within a 64 kbit/s channel. 
ITU G.723 Recommendation for dual rate speech coder for 
multimedia communication transmitting at 5.3 and 6.3 
55 kbits. 

ITU G.728 Recommendation for coding of speech at 16 
kbit/s using low-delay code excited linear prediction 
(LD-CELP) 

ITU H.221 Frame Structure for a 64 to 1920 kbit/s Channel 
60 in Audiovisual Teleservices 

ITU H.223 Multiplexing Protocols for Low Bitrate Multi- 
media Terminals 
ITU H.225 ITU Recommendation for Media Stream Pack- 
etization and Synchronization on non-guaranteed quality 
65 of service LANs. 

ITU H.230 Frame-synchronous Control and Indication Sig- 
nals for Audiovisual Systems 
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ITU H.231 Multipoint Control Unit for Audiovisual Systems 

Using Digital Channels up to 2 Mbit/s 
ITU H.242 System for Establishing Communication 

Between Audiovisual Terminals Using Digital Channels 

up to 2 Mbits 

ITU H.243 System for Establishing Communication 

Between Three or More Audiovisual Terminals Using 

Digital Channels up to 2 Mbit/s 
ITU H.245 Recommendation for a control protocol for 

multimedia communication 
ITU H.261 Recommendation for Video Coder-Decoder for 

audiovisual services supporting video resolutions of 352x 

288 pixels and 176x144 pixels. 
ITU H.263 Recommendation for Video Coder-Decoder for 

audiovisual services supporting video resolutions of 128 x 

96 pixels, 176x144 pixels, 352x288 pixels, 704x576 

pixels and 1408x1152 pixels. 
ITU H.320 Recommendation for Narrow Band ISDN visual 

telephone systems. 
ITU H.321 Visual Telephone Terminals over ATM 
ITU H.322 Visual Telephone Terminals over Guaranteed 

Quality of Service LANs 
ITU H.323 ITU Recommendation for Visual Telephone 

Systems and Equipment for Local Area Networks which 

provide a non-guaranteed quality of service. 
ITU H.324 Recommendation for Terminals and Systems for 

low bitrate(28.8 Kbps) multimedia communication on 

dial-up telephone lines. 
ITU T.120 Transmission Protocols for Multimedia Data. 

In addition, several other relevant standards exist includ- 
ing: 

ISDN Integrated Services Digital Network, the digital com- 
munication standard for transmission of voice, video and 
data on a single communications link. 

RTP Real-Time Transport Protocol, an Internet Standard 
Protocol for transmission of real-time data like voice and 
video over unicast and multicast networks. 

IP Internet Protocol, an Internet Standard Protocol for trans- 
mission and delivery of data packets on a packet switched 
network of interconnected computer systems. 

PPP Point-to-Point Protocol 

MPEG Motion Pictures Expert Group, a standards body 
under the International Standards Organization(ISO), 
Recommendations for compression of digital Video and 
Audio including the bit stream but not the compression 
algorithms. 
SLIP Serial Line Internet Protocol 
RSVP Resource Reservation Setup Protocol 
UDP User Datagram Protocol 

The popularity of the TCP/IP protocols on the Internet 
grew rapidly because they met an important need for world- 
wide data communication and had several important char- 
acteristics that allowed them to meet this need. These^ 
characteristics, still in use today, include: 

1) A common addressing scheme that allows any device 
running TCP/IP to uniquely address any other device on 
the Internet. 

2) Open protocol standards, freely available and developed 
independently of any hardware or operating system. Thus, 
TCP/IP is capable of being used with different hardware 
and software, even if Internet communication is not 
required. 

Independence from any specific physical network 
hardware, allows TCP/IP to integrate many different kinds of 
networks. TCP/IP can be used over an Ethernet, a token ring, 
a dial-up line, or virtually any other kinds of physical 
transmission media. 



11,518 

42 

An understanding of how information travels in commu- 
nication systems is required to appreciate the recent steps 
taken by key players in today's Internet backbone business. 
The traditional type of communication network is circuit 

s switched. The U.S. telephone system uses such circuit 
switching techniques. When a person or a computer makes 
a telephone call, the switching equipment within the tele- 
phone system seeks out a physical path from the originating 
telephone to the receiver's telephone. A circuit-switched 
network attempts to form a dedicated connection, or circuit, 
between these two points by first establishing a circuit from 
the originating phone through the local switching office, then 
across trunk lines, to a remote switching office, and finally 
to the destination telephone. This dedicated connection 
exists until the call terminates, 

15 The establishment of a completed path is a prerequisite to 
the transmission of data for circuit switched networks. After 
the circuit is in place, the microphone captures analog 
signals, and the signals are transmitted to the Local 
Exchange Carrier (LEC) Central Office (CO) in analog form 

20 over an analog loop. The analog signal is not converted to 
digital form until it reaches the LEC Co, and even then only 
if the equipment is modern enough to support digital infor- 
mation. In an ISDN embodiment, however, the analog 
signals are converted to digital at the device and transmitted 

25 to the LEC as digital information. ■ 

Upon connection, the circuit guarantees that the samples 
can be delivered and reproduced by maintaining a data path 
of 64 Kbps (thousand bits per second). This rate is not the 
rate required to send digitized voice per se. Rather, 64 Kbps 

30 is the rate required to send voice digitized with the Pulse 
Code Modulated (PCM) technique. Many other methods for 
digitizing voice exist, including ADPCM (32 Kbps), GSM 
(13 Kbps), TrueSpeech 8.5 (8.5 Kbps), G.723 (6.4 Kbps or 
5.3 Kbps) and Voxware RT29HQ (2.9 Kbps). Furthermore, 

35 the 64 Kbps path is maintained from LEC Central Office 
(CO) Switch to LEC CO, but not from end to end. The 
analog local loop transmits an analog signal, not 64 Kbps 
digitized audio. One of these analog local loops typically 
exists as the "last mile" of each of the telephone network 

40 circuits to attach the local telephone of the calling party. 

This guarantee of capacity is the strength of circuit- - 
switched networks. However, circuit switching has two 
significant drawbacks. First, the setup time can be 
considerable, because the call signal request may find the 

45 lines busy with other calls; in this event, there is no way to 
gain connection until some other connection terminates. 
Second, utilization can be low while costs are high. In other 
words, the calling party is charged for the duration of the call 
and for all of the time even if no data transmission takes 

50 place (i.e. no one speaks). Utilization can be low because the 
time between transmission of signals is unable to be used by 
any other calls, due to the dedication of the line. Any such 
unused bandwidth during the connection is wasted. 

Additionally, the entire circuit switching infrastructure is 

55 built around 64 Kbps circuits. The infrastructure assumes the 
use of PCM encoding techniques for voice. However, very 
high quality codecs are available that can encode voice using 
less than one -tenth of the bandwidth of PCM. However, the 
circuit switched network blindly allocates 64 Kbps of band- 

60 width for a call, end-to-end, even if only one -tenth of the 
bandwidth is utilized. Furthermore, each circuit generally 
only connects two parties. Without the assistance of confer- 
ence bridging equipment, an entire circuit to a phone is 
occupied in connecting one party to another party. Circuit 

65 switching has no multicast or multipoint communication 
capabilities, except when used in combination with confer- 
ence bridging equipment. 
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Other reasons for long call setup time include the different 
signaling networks involved in call setup and the sheer 
distance causing propagation delay. Analog signaling from 
an end station to a CO on a low bandwidth link can also 
delay call setup. Also, the call setup data travels great 
distances on signaling networks that are not always trans- 
mitting data at the speed of light. When the calls are 
international, the variations in signaling networks grows, the 
equipment handling call setup is usually not as fast as 
modem setup and the distances are even greater, so call setup 
slows down even more. Further, in general, connection- 
oriented virtual or physical circuit setup, such as circuit 
switching, requires more time at connection setup time than 
comparable connectionless techniques due to the end-to-end 
handshaking required between the conversing parties. 

Message switching is another switching strategy that has 
been considered. With this form of switching, no physical 
path is established in advance between the sender and 
receiver; instead, whenever the sender has a block of data to 
be sent, it is stored at the first switching office and retrans- 
mitted to the next switching point after error inspection. 
Message switching places no limit on block size, thus 
requiring that switching stations must have disks to buffer 
long blocks of data; also, a single block may tie up a line for 
many minutes, rendering message switching useless for 
interactive traffic. 

Packet switched networks, which predominate the com- 
puter network industry, divide data into small pieces called 
packets that are multiplexed onto high capacity intermachine 
connections. A packet is a block of data with a strict upper 
limit on block size that carries with it sufficient identification 
necessary for delivery to its destination. Such packets usu- 
ally contain several hundred bytes of data and occupy a 
given transmission fine for only a few tens of milliseconds. 
Delivery of a larger file via packet switching requires that it 
be broken into many small packets and sent one at a time 
from one machine to the other. The network hardware 
delivers these packets to the specified destination, where the 
software reassembles them into a single file. 

Packet switching is used by virtually all computer inter- 
connections because of its efficiency in data transmissions. 
Packet switched networks use bandwidth on a circuit as 
needed, allowing other transmissions to pass through the 
fines in the interim. Furthermore, throughput is increased by 
the fact that a router or switching office can quickly forward 
to the next stop any given packet, or portion of a large file, 
that it receives, long before the other packets of the file have 
arrived. In message switching, the intermediate router would 
have to wait until the entire block was delivered before 
forwarding. Today, message switching is no longer used in 
computer networks because of the superiority of packet 
switching. 

To better understand the Internet, a comparison to the 
telephone system is helpful. Hie public switched telephone 
network was designed with the goal of transmitting human 
voice, in a more or less recognizable form. Their suitability 
has been improved for computer-to-computer communica- 
tions but remains far from optimal. A cable running between 
two computers can transfer data at speeds in the hundreds of 
megabits, and even gigabits per second. A poor error rate at 
these speeds would be only one error per day. In contrast, a 
dial-up line, using standard telephone lines, has a maximum 
data rate in the thousands of bits per second, and a much 
higher error rate. In fact, the combined bit rate times error 
rate performance of a local cable could be 11 orders of 
magnitude better than a voice-grade telephone line. New 
technology, however, has been improving the performance 
of these lines. 
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The Internet is composed of a great number of individual 
networks, together forming a global connection of thousands 
of computer systems. After understanding that machines are 
connected to the individual networks, we can investigate 

S how the networks are connected together to form an 
internetwork, or an internet. At this point, internet gateways 
and internet routers come into play. 

In terms of architecture, two given networks are con- 
nected by a computer that attaches to both of them. Internet 

10 gateways and routers provide those links necessary to send 
packets between networks and thus make connections pos- 
sible. Without these links, data communication through the 
Internet would not be possible, as the information either 
would not reach its destination or would be incomprehen- 

15 sible upon arrival. A gateway may be thought of as an 
entrance to a communications network that performs code 
and protocol conversion between two otherwise incompat- 
ible networks. For instance, gateways transfer electronic 
mail and data files between networks over the internet. 

20 IP Routers are also computers that connect networks and 
is a newer term preferred by vendors. These routers must 
make decisions as to how to send the data packets it receives 
to its destination through the use of continually updated 
routing tables.. By analyzing the destination network address 

25 of the packets, routers make these decisions. Importantly, a 
router does not generally need to decide which host or end 
user will receive a packet; instead, a router seeks only the 
destination network and thus keeps track of information 
sufficient to get to the appropriate network, not necessarily 

30 the appropriate end user. Therefore, routers do not need to be 
huge supercomputing systems and are often just machines 
with small main memories and little disk storage. The 
distinction between gateways and routers is slight, and 
current usage blurs the line to the extent that the two terms 

35 are often used interchangeably. In current terminology, a 
gateway moves data between different protocols and a router 
moves data between different networks. So a system that 
moves mail between TCP/IP and OSI is a gateway, but a 
traditional IP gateway (that connects different networks) is a 

40 router. 

Now, it is useful to take a simplified look at routing in 
traditional telephone systems. The telephone system is orga- 
nized as a highly redundant, multilevel hierarchy. Each 
telephone has two copper wires coming out of it that go 

45 directly to the telephone company's nearest end office, also 
called a local central office. The distance is typically less 
than 10 km; in the U.S. alone, there are approximately 
20,000 end offices. The concatenation of the area code and 
the first three digits of the telephone number uniquely 

so specify an end office and help dictate the rate and billing 
structure. 

The two-wire connections between each subscriber's tele- 
phone and the end office are called local loops. If a sub- 
scriber attached to a given end office calls another subscriber 

55 attached to the same end office, the switching mechanism 
within the office sets up a direct electrical connection 
between the two local loops. This connection remains intact 
for the duration of the call, due to the circuit switching 
techniques discussed earlier. 

60 If the subscriber attached to a given end office calls a user 
attached to a different end office, more work has to be done 
in the routing of the call. First, each end office has a number 
of outgoing lines to one or more nearby switching centers, 
called toll offices. These lines are called toll connecting 

65 trunks. If both the caller's and the receiver's end offices 
happen to have a toll connecting trunk to the same toll office, 
the connection may be established within the toll office. If 
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the caller and the recipient of the call do not share a toll 
office, then the path will have to be established somewhere 
higher up in the hierarchy. There are sectional and regional 
offices that form a network by which the toll offices are 
connected. The toll, sectional, and regional exchanges com- 
municate with each other via high bandwidth inter-toll 
trunks. The number of different kinds of switching centers 
and their specific topology varies from country to country, 
depending on its telephone density. 

Using Network Level Communication for Smooth 
User Connection 

In addition to the data transfer functionality of the 
Internet, TCP/IP also seeks to convince users that the 
Internet is a solitary, virtual network. TCP/IP accomplishes 
this by providing a universal interconnection among 
machines, independent of the specific networks to which 
hosts and end users attach. Besides router interconnection of 
physical networks, software is required on each host to allow 
application programs to use the Internet as if it were a single, 
real physical network. 

The basis of Internet service is an underlying, connec- 
tionless packet delivery system run by routers, with the basic 
unit of transfer being the packet. In internets running TCP/ 
IP, such as the Internet backbone, these packets are called 
datagrams. This section will briefly discuss how these data- 
grams are routed through the Internet. 

In packet switching systems, routing is the process of 
choosing a path over which to send packets. As mentioned 
before, routers are the computers that make such choices. 
For the routing of information from one host within a 
network to another host on the same network, the datagrams 
that are sent do not actually reach the Internet backbone. 
This is an example of internal routing, which is completely 
self-contained within the network. The machines outside of 
the network do not participate in these internal routing 
decisions. 

At this stage, a distinction should be made between direct 
delivery and indirect delivery. Direct delivery is the trans- 
mission of a datagram from one machine across a single 
physical network to another machine on the same physical 
network. Such deliveries do not involve routers. Instead, the 
sender encapsulates the datagram in a physical frame, 
addresses it, and then sends the frame directly to the 
destination machine. 

Indirect delivery is necessary when more than one physi- 
cal network is involved, in particular when a machine on one 
network wishes to communicate with a machine on another 
network. This type of communication is what we think of 
when we speak of routing information across the Internet 
backbone. In indirect delivery, routers are required. To send 
a datagram, the sender must identify a router to which the 
datagram can be sent, and the router then forwards the 
datagram towards the destination network. Recall that rout- 
ers generally do not keep track of the individual host 
addresses (of which there are millions), but rather just keeps 
track of physical networks (of which there are thousands). 
Essentially, routers in the Internet form a cooperative, inter- 
connected structure, and datagrams pass from router to 
router across the backbone until they reach a router that can 
deliver the datagram directly. 

The changing face of the internet world causes a steady 
inflow of new systems and technology. The following three 
developments, each likely to become more prevalent in the 
near future, serve as an introduction to the technological 
arena. 
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Asynchronous Transfer Mode (ATM) is a networking 
technology using a high-speed, connection-oriented system 
for both local area and wide area networks. ATM networks 
require modem hardware including: 

1) High speed switches that can operate at gigabit (trillion 
bit) per second speeds to handle the traffic from many 

, computers. 

2) Optical fibers (versus copper wires) that provide high data 
transfer rates, with host- to -ATM switch connections run- 
ning at 100 or 155 Mbps (million bits per second). 

3) Fixed size cells, each of which includes 53 bytes. 
ATM incorporates features of both packet switching and 

circuit switching, as it is designed to carry voice, video, and 
television signals in addition to data. Pure packet switching 
technology is not conducive to carrying voice transmissions 
because such transfers demand more stable bandwidth. 

Frame relay systems use packet switching techniques, but 
are more efficient than traditional systems. This efficiency is 
partly due to the fact that they perform less error checking 
than traditional X.25 packet-switching services. In fact, 
many intermediate nodes do little or no error checking at all 
and only deal with routing, leaving the error checking to the 
higher layers of the system. With the greater reliability of 
today's transmissions, much of the error checking previ- 
ously performed has become unnecessary. Thus, frame relay 
offers increased performance compared to traditional sys- 
tems. 

An Integrated Services Digital Network is an "interna- 
tional telecommunications standard for transmitting voice, 
video, and data over digital lines/' most commonly running 
at 64 kilobits per second. The traditional phone network runs 
voice at only 4 kilobits per second, To adopt ISDN, an end 
user or company must upgrade to ISDN terminal equipment, 
central office hardware, and central office software. The 
ostensible goals of ISDN include the following: 

1) To provide an internationally accepted standard for voice, 
data and signaling; 

2) To make all transmission circuits end-to-end digital; 

3) To adopt a standard out-of-band signaling system; and 

4) To bring significantly more bandwidth to the desktop. 
An ISP is composed of several disparate systems. As ISP 

integration proceeds, formerly independent systems now 
become part of one larger whole with concomitant increases 
in the level of analysis, testing, scheduling, and training in 
all disciplines of the ISP. 

Internet-Based Callback Architecture 

The following information discusses the detailed archi- 
tecture of an internet-based callback architecture in accor- 
dance with a preferred embodiment. A block diagram of the 
architecture is illustrated in FIG. 114 in accordance with a 
preferred embodiment. The callback call flow commences 
when a caller 11412 calls into a local internet service 
provider 11419 as illustrated in FIG. 114 at 11410. The caller 
addresses the callback server 11414 to access the callback 
home page 11411 through the internet 11419, shown as an 
internet cloud labeled Basic Inemet Protocol Platform 
11419. At the callback server home page 11411, the caller 
enters, sees and/or updates default information such as: 
callback Internet Protocol (IP) address, call-to phone num- 
ber (or multiple phone numbers to initiate a conference call) 
and charge-to method at a minimum. Other information, 
such as one or more numbers comprising entry of a Direct 
Distance Dialing (DDD), International Direct Distance Dial- 
ing (IDDD) or an Internet Protocol (IP) address can be 
utilized to specify a phone number or internet computer with 
voice capability. In addition, a date and time can be prear- 
ranged for staging the callback operation. Additional infor- 
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mation that can be captured at the callback server home page 
11411 is detailed below in specific examples designed to 
elaborate and clarify in accordance with a preferred embodi- 
ment. 

Then, at 11420, the callback server 11414 send a message 
to the callback switch 11432 with the appropriate calling 
information, and the callback switch 11432 initiates the 
callback leg as shown by step 11430 of the call through the 
Public Service Telephony Network (PSTN) 11435 to the 
destination specified by the caller whereby the callback 
caller answers the incoming call to 11437. Once the caller 
end of the call is prepared, then the callback switch initiates 
call-to call leg(s) which connect the call through path 11440 
through PSTN 11445 to telephone set 11446 and/or 11447. 
Once all of the callers have been connected, then when the 
status of the call changes, an exception condition is indicated 
on the display if it is an IP call, or an audio indicia of the 
condition is transmitted to the callers if they are utilizing a 
standard telephony device. A change in status could be a 
caller hanging up or a glitch occurring in the transmission. 
The exception conditions are also captured for quality of 
service analysis. 

When the call is initiated utilizing the information entered 
into the callback server home page 11411, as part of the 
initialization of the callback session, a separate temporary 
webpage is created which is accessible to all members of the 
callback via a password selected by the initiator of the 
callback session. While all of the callers are being connected 
and throughout the duration of the telephony experience, the 
status of the call leg changes, and exception conditions, are 
indicated on the temporary created status webpage, or an 
audio indicia, where appropriate, of the condition is trans- 
mitted to the callers if they are utilizing a standard telephony 
device. Then, as callers are connected, removed, or change 
status, the display is updated to reflect the status of each 
participant's connection. In addition, as the call progresses, 
participants can drag and drop files, video clips or any other 
information which would be utilized as collaborative mate- 
rial during the call. Each participant would be required to 
move information to their personal computer before the call 
terminated, since the webpage is temporary and is deleted 
upon termination of the call. The temporary webpage is 
password protected to avoid unauthorized access to the 
information contained in the webpage. 

Callback Service Potential 
The callback service includes support for one-to-one calling, 
one-to-many calling (conference calling, fax broadcast, 
text-to-speech message delivery, voice-to-voice message 

delivery, 

conference call reservation whereby the server sends 
E-mails to call-to participants with the conference call 
details, the server sends fax to call-to participants, or the 
server sends a text-to-speech message to call-to partici- 
pants. 

Internet Service Potential 

Real-time view of the status of each conference call 
participant, ANI and an alphanumeric representation to 
identify each participant entered by the initiator when a call 
is "reserved" can be displayed on screen as participants 
connect to conference. This information is captured as part 
of the call record set forth earlier and detailed in the 
appendix. 

In an alternative embodiment, a conference call without 
callback leg is enabled. In this embodiment, a callback 
customer participates through a Voice Over Network (VON) 
application utilizing a computer with voice capability, and 
can initiate a video screen popup on the computer display for 
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manual operator assistance as detailed above in the descrip- 
tion of a video operator. 

Internet-Based Callback Architecture 

In an internet based callback architecture as illustrated in 

5 FIG. 115, the callback caller dials into a local internet 
service provider 11512. Then, the caller addresses the host 
server 11514 containing the callback home page 
11510—11511. At the callback server home page 11511, the 
caller enters the information described earlier including a 

10 callback Internet Protocol (IP) address, call-to phone num- 
ber (or multiple phone numbers to initiate a conference call) 
and charge-to method at a minimum. Then, for the callback 
call flow to initiate the call, the callback server 11514, where 
the callback server home page 11511 is located, transmits a 

is message to the callback switch 11532 with the necessary 
calling information generated from the callback home page 
11511. Finally, the callback switch 11532, establishes an 
internet voice session with the callback caller utilizing the 
internet service provider 11512 to establish a voice IP 

20 session with the initiating client 11535. The callback switch 
11511 then initiates the call-to call leg(s) routing the call 
11540 out over the public service telephony network 11541 
to a telephone set 11542. 
Self-Regulating System 

25 An expert system monitors each call in accordance with 
a preferred embodiment. The system includes rules that 
define what logic to execute when an exception occurs. The 
rules include specialized processing based on whether the 
call is routed via a PSTN or the internet. In addition, the 

30 system includes a default connection to a manual operator if 
no other correction of the connection is available. For 
example, if a caller hangs up during a teleconference and 
other callers are still connected, an exception message is sent 
to each of the still connected callers informing them of the 

35 status change. Another aspect of the expert system is to 
ensure quality of service (QOS) and produce reports indi- 
cating both integrity and exceptions. Scheduling of 
resources is tied to this expert system, which regulates 
whether calls can be scheduled based on available or pro- 

40 jected resources at the time of the proposed call. For 
example, since all calls used by this system are initiated by - 
the callback switch (item 11432 in FIG. 114 and item 11532 
in FIG. 115), if there are insufficient outgoing trunk ports 
during the period of time that a callback subscriber requests, 

45 then the callback subscriber is prompted to select another 
time or denied access to the resources for that time. This is 
utilized to predict when additional ports and/or resources are 
required. 

Fault Management 

50 The NGN operations architecture specifies the points of 
insertion and collections for network wide events that feed 
the Fault Management systems. Since the components of the 
packet portion of the hybrid NGN infrastructure are in most 
cases manageable by SNMP or some other standard man- 

55 agement protocol the major challenges are the following: 
1. Correlation of the events from the packet infrastructure 
with the Core circuit-based network events to provide the 
operators with a seamless service oriented view of the 
overall health of the network; 

60 2. Event gathering and interpretation from the Core circuit 
network elements; and 
3. Mediation and standardization of the network messages to 
aid processing by the network management framework of 
the NGN. 

65 The network management components of the NGN pro- 
vide comprehensive solutions to address these challenges. 
Correlation is provided by the use of rules based inference 
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engines. Event gathering and interpretation is typically 
performed by custom development of software interfaces 
which communicate directly with the network elements, 
process raw events and sort them by context prior to storing 
them. For example, alarms versus command responses. The 
mediation and standardization challenge is addressed by 
using a comprehensive library of all possible message types 
and network events categorize the numerous messages that 
the NGN generates. 

FIG. 15A is a flowchart showing a Fault Management 
Process 1550 in accordance with a preferred embodiment of 
the present invention. The Fault Management Process 1550 
begins with a transmitting step 1552. In step 1552, data is 
transmitted over the hybrid network, including video and 
mixed audio information. The data transmission generally 
makes full use of the hybrid networks mixed circuit- 
switched an packet-switched components. As discussed 
above, the hybrid network includes approximately all the 
advantages of a packet based network while still making use 
of the older circuit-switched components already in place. 
The system is able to do this by correlating events raised by 
both the circuit-switched and packet-switch network 
elements, as discussed later in relation to event and corre- 
lating steps 1554 and 1556. 

In a circuit-switched event gathering step 1554, an event 
is obtained from a circuit -switched based network element. 
As discussed above, event gathering and interpretation is 
typically performed by custom developed software inter- 
faces which communicate directly with the network 
elements, process raw network events, and sort the events by 
context prior to storing them. After obtaining the events, the 
events are correlated in a correlation step 1556. 

In a correlation step 1556, the event gathered in step 1554 
is correlated with a second event obtained from a packet- 
switched network element. As with circuit-switched network 
elements, packet-switched event gathering and interpreta- 
tion is typically performed by custom developed software 
interfaces which communicate directly with the network 
elements, process raw network events, and sort the events by 
context prior to storing them. As discussed above, the 
" correlation is preferably provided by a rules based inference 
engine. After the events are correlated, a fault message is 
created in a fault message step 1558. 

In a fault message step 1558, a fault message is created 
based on the correlated first and second events obtained in 
steps 1554 and 1556. Preferably the fault message is created 
utilizing a comprehensive library of all possible message 
types and network events which categorizes the numerous 
messages that the hybrid network generates. 

FIG. 15B is a block diagram showing a Fault Manage- 
ment component 1500 in accordance with a preferred 
embodiment of the present invention. The Fault Manage- 
_ ment component .1500 records failures and_ exceptions in_ 
network devices (e.g. network routers or UNIX servers) and 
performs the following operations: 

1) performs root-cause correlation of the failures and excep- 
tions; 

2) immediately takes corrective and/or informative actions 
such as sending a page, logging a help desk ticket, sending 
an electronic mail message, or calling a resolution script; 

3) stores the information into a Database Component for 
later analysis by the Reporting Component; and 

4) allows real time viewing of faults in a network map and 
network event views. The Fault Management component 
1500 includes the following elements: 

UNIX Servers 1502— Any UNIX Server with BMC Patrol 
clients loaded. 
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NT Servers 1504 — Any NT Server with BMC Patrol clients 
loaded. 

SNMP Devices 1506— Any SNMP manageable device. 

HP OV Network Node Manager (Collector Component) 
5 1508 — HP Open View Network Node Manager is one 
product which performs several functions. In this context 
it is it is responsible for receiving performance informa- 
tion from BMC Patrol clients via BMC Patrol View. 

Seagate NerveCenter 1510 — In a fault management context, 
Seagate NerveCenter performs root-cause correlation of 
faults and events across the network. 

HP OV Network Node Manager Network Map 1512— HP 
OpenView Network Node Manager is one product which 
performs several functions. In this context it is respon- 
sible for maintaining and displaying the node level net- 
15 work map of the network the MNSIS architecture moni- 
tors. 

HP OV Network Node Manager 1514— HP OpenView 
Network Node Manager is one product which performs 
several functions. In this context it is it is responsible for 
20 receiving and displaying all events, regardless of their 
source. 

Netcool HP OV NNM Probe 1516— An Omnibus Netcool 
probe which is installed on the same system as HP OV 
Network Node Manager and forwards events to the Omoi- 

25 bus Netcool Object Server. 

Micromuse Internet Service Monitors 1518 — An Omnibus 
Netcool suite of active probes (monitors) which monitor 
internet services such as FTP, POP3, SMTP, NNTP, DNS, 
HTTP, and RADIUS. These monitors collect availability 

30 and performance data and forward the information as 
alerts to the Omnibus Netcool Object Server. 
Netcool Object Server 1520 — The Omnibus Netcool Object 
Server is a real-time memory resident database which 
stores all current events (alerts). The events are viewable 

35 by operations personnel using a number of event lists and 
views, all of which are highly customizable by each 
operator. 

Notification Spooler 1522 — A custom provided sub- 
component which spools job-files that specify which 

40 events have occurred for possible notifications. 
-- Spooled Job 1524 — Each spooled job represents a specific - 
event that was received by the Netcool Object Server and 
may need to result in one or more notification actions. 
Each job is stored as a file in a special notification spool 

45 directory. 

Notification Actor 1526 — A custom provided sub- 
component which determines the alert time, source node, 
and alert type from the loaded spooled job and initiates 
notification actions based as specified in the configuration 

50 file. Notification actions include alphanumeric pages, 
trouble tickets, email, and resolution scripts. Multiple 
notification actions can be specified in the configuration 
files such that different actions.are taken for different.alert 
times, source nodes, and/or alert types. Default actions are 

55 also supported. 

Alphanumeric Page 1528 — An alphanumeric page sent 
using Telamon TelAlert via modem dialing the relevant 
paging provider. The alphanumeric page message pro- 
vides contextual notification of actions to be performed. 

60 Context can include any information but frequently con- 
tains information such as the device name, problem 
description, and priority. 
Electronic Mail Message 1530 — An internet mail message 
send using the UNIX mail utility. The mail message is 

65 frequently used to provide non-urgent notification of 
situations or actions automatically performed by the 
MNSIS architecture along with detailed context. 
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Local Script Execution 1532 — Initiates any local script on 
the machine, which may initiate scripts or applications on 
other machines. 

Remedy Gateway 1534 — The Omnibus Netcool Remedy 
Gateway automatically reads alerts in the Netcool Object 
Server and opens tickets within Remedy as customized by 
the user. The Remedy trouble ticket ID is returned to the 
Omnibus and can be viewed as further reference. 

Remedy 1536 — Remedy Action Request System, a trouble 
ticketing system. 

Oracle Gateway 1538 — The Omnibus Netcool Oracle Gate- 
way automatically reads alerts in the Netcool Object 
Server and logs records within Oracle as customized by 
the user. 

Oracle 1540 — Oracle is a relational database management 
system, 

Generate Time Key Script 1542 — Script which generates 
New Time Records from alerts in the Netcool Object 
Server. 

New Time Records 1544 — Time records corresponding to 
new alerts in Netcool Object Server which need to be 
added to the Oracle time tables, 

SQL Loader Script 1546 — A custom script which automati- 
cally loads records into Oracle via SQL Loader Direct 
Load. 

Proactive Threshold Manager 

The Proactive Threshold Manager is an automated net- 
work manager that forewarns service providers of a chance 
that a service level agreement to maintain a certain level of 
service is in danger of being breached. 

The Proactive Threshold Manager provides real-time 
threshold analysis (that is, it continuously monitors for plan 
thresholds that have been exceeded) using algorithms. It 
receives call detail records from the Server and returns 
alarms which may be retrieved and examined using an NGN 
workstation. The threshold manager resides on an NGN 
hybrid network computer, 

A threshold generally is a number which, when exceeded, 
generates an alarm in the Proactive Threshold Manager 
indicating possible breach of a service level agreement. 
Thresholds may be specified for the time of day and/or the 
day of the week. Furthermore, a threshold may be applied to 
each category for which the Proactive threshold manager 
keeps counts, including the number of short-duration calls, 
long^duration calls, and cumulative minutes. 

When an alarm is generated by the Proactive Threshold 
Manager, it is also prioritized. The priority is a multiple of 
the number of times a threshold has been exceeded. For 
example, if the threshold was 10 and the relevant count has 
reached 50, then the priority of the alarm is 5 (50.div.10). 

Each alarm is available to an NGN hybrid network analyst 
via an NGN Workstation. The workstation is a PC with 
access to a Server and retrieves the next available alarm of 
the highest priority. The analyst investigates the alarm data 
and, if a service level agreement breach is suspected, notifies 
the provider and suggests appropriate actions to stop the 
breach. 

FIG. 16A is a flowchart showing a Proactive Threshold 
Management Process 1600 in accordance with a preferred 
embodiment of the present invention. The process begins 
with a monitoring step 1602. In step 1602, the Proactive 
Threshold Manager monitors the NGN hybrid network. The 
Proactive Threshold Manager generally monitors the net- 
work at all times to ensure proper service is provided to 
subscribers of the network, by assisting service providers in 
maintaining a proper level of service. 

In a minimum level determination step 1604, the Proac- 
tive Threshold Manager determines the minimum level of 
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service needed to avoid breaching subscriber service level 
agreements. Service level agreement information is gener- 
ally provided to the Proactive Threshold Manager by the 
rules database which contains most pertinent subscriber 
information. 

In a sensing step 1606, the Proactive Threshold Manager 
senses the current level of service which is being provided 
to customers. Protocol converters assist the Proactive 
Threshold Manager in communicating with various compo- 
nents of the system. Protocol converters are able to translate 
information between the packet-switched an circuit- 
switched system components, thus allowing the Proactive 
Threshold Manager to communicate with all the components 
of the hybrid system. 

In a comparing step 1608, the Proactive Threshold Man- 
ager compares the current level of service, sensed in step 
1606, with the minimum level of service, determined in step 
1604, to determine where the current level of service is in 
relation to the minimum level service which needs to be 
provided to subscribers. 

In an alarm step 1610, the Proactive Threshold Manager 
provides an indication or alarm to the service provider if the 
current level of service is within a predetermined range with 
respect to the minimum level of service. The threshold is 
preferably chosen such that the service provider is allowed 
enough time to cure the service level problem before the 
minimum service level is reached and the subscriber's 
service level agreement breached. 

FIG. 16B is a flowchart showing a Network Sensing 
Process 1620 in accordance with one embodiment of the 
present invention. The Network Sensing Process 1620 
begins with an element monitoring step 1622. In step 1622, 
custom developed element software monitors the individual 
network elements and generates events based on hardware 
occurrences, such as switch failures. Typically, the various 
elements that make up the hybrid network are very different 
from one another. Thus, custom software is generally needed 
for each network element or group of related network 
elements. The custom developed software communicates 
directly with the hardware and generates events when vari- 
ous occurrences related to the individual hardware happens. 
For example, when a hardware element fails, the related 
element software senses the failure and generates an event 
indicating the hardware failure and the general nature of the 
failure. The events are then routed to an element manger to 
processed. 

In an event processing step 1624, events generated in step 
1622 are filtered, aggregated, and correlated by an element 
manager. The element manager is where the primary data 
reduction functions reside. The element manager filters, 
aggregates, and correlates the events to further isolate prob- 
lems within the network. Any information that is deemed 
critical to monitor and manage the network is translated into 
standard object format in a translation step 1626. 

In a translation step 1626, information from step 1624 that 
is deemed critical to monitor and manage the network is 
translated into a standard object format. Generally, typical 
operational events are only logged and not translated into 
standard object format. However, critical information, such 
as hardware failure, is translated and forwarded to the 
Information Services Manager in an information provision- 
ing step 1628. 

In an information provisioning step 1628, information 
from step 1626 is received by the Information Services 
Manager and forwarded to the Proactive Threshold Man- 
ager. The Information Services Manager provides the data 
management and data communications between the element 
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manager and other system components. Generally, the Infor- 
mation Services Manager adheres to CORBA standards to 
provide universal information access by an object request 
broker. The object request broker allows the Information 
Services Manager to share management information stored 5 
in distributed databases. The Proactive Threshold Manager 
uses the information provided by the Information Services 
Manger to determine a current level of service and compare 
the current level of services with the minimum level of 
service that the service provider can provide without vio 
lating SLAs. 

Element Management 

As discussed above, the element manager works with the 
Information Services Manager and the Presentation Man- 
ager to assist in the management of the hybrid network 
system. The three components are briefly described below to 15 
provide context for the detailed discussion of the element 
manager that follows. 

Element Manager 

The element manager communicates with the network 
elements to receive alarms and alerts through trapping 
and polling techniques. The element manager is the 
layer where the primary data reduction functions 
reside. At this layer, events received at the element 
manager will be filtered, aggregated and correlated to 
further isolate problems within the network. Informa- 
tion that is deemed critical to monitor and manage the 
network is translated into a standard object format and 
forwarded to the Information Services Manager. An 
element manager can be, but is not necessarily, soft- 3Q 
ware which adheres to open standards such as the 
Simple Network Management Protocol (SNMP) and 
the Object Management Group's (OMG) Common 
Object Request Broker Architecture (CORBA). 

Information Services Manager 35 

The information services manager provides the data man- 
agement and data communications between element 
managers and presentation managers. All information 
forwarded from the element managers is utilized by the 
information services manager to provide information to 4Q 
the network operators. The information services man- 
ager adheres to CORBA standards to provide ubiqui- 
tous information access via an object request broker 
(ORB), The ORB allows the information services man- 
ager to share management information stored in dis- 45 
tributed databases. 

The information services manager stores critical manage- 
ment information into operational (real-time) and ana- 
lytical (historical) distributed databases. These data- 
bases provide common data storage so that new 50 
products can be easily inserted into the management 
environment. For example, if an event is received at an 
element manager that is deemed critical to display to a 
network user, the information services manager will 
store a copy of the alarm in the operational database 55 
and then forward the alarm to the appropriate network 
operator. 

Media and textual databases are also provided by the 
information services manager. The databases includes 
online manuals for administrative purposes, as well as $o 
for the maintenance specialists to access element spe- 
cific information. The databases also provide 
procedures, policies and computer based training to 
network users. 

The information services manager provides requested 65 
information (real-time and historical) to the network 
users via the presentation manager. 



Presentation Manager 

The presentation manager performs the function its name 
implies: the presentation of the information to an end user. 
Because different locations and job functions require access 
to different types of information, there are at least two types 
of display methods. The first is for graphic intensive pre- 
sentations and the second is for nomadic use, such as field 
technicians. The first environment requires a graphic inten- 
sive display, such as those provided by X-Windows/MOHF. 
The second environment is potentially bandwidth poor 
where dial-up or wireless access may be used along with 
more traditional LAN access. This is also where browser 
technology is employed. 

The Element Management Aspect of the present invention 
works in conjunction with other components of the system, 
such as Fault Management, to provide communication 
between the various network elements of the system. 

FIG. 17 is a flowchart showing an Element Management 
Process 1700 in accordance with a preferred embodiment of 
the present invention. The Element Management Process 
1700 begins with a monitoring step 1702. In step 1702, the 
Element Manager monitors the system for events generated 
by network elements. Generally, the Element Manager con- 
tinuously monitors the system to translate events for other 
system components, such as the Fault Management Com- 
ponent. 

In an event receiving step 1704, the Element Manager 
receives events from various network elements. Preferably 
the events are provided by custom software interfaces which 
communicate directly with network elements. The software 
interfaces preferably process the raw network events and 
sort them by context prior to providing the events to the 
Element Manager. 

In a filtering and correlating step 1706, the Element 
Manager filters and correlates the events received in step 
1704. Preferably the correlation is provided by a rules based 
inference engine. After collecting and correlating the events, 
the Element Manager performs a translation step 1708. In 
step 1708, the events correlated in step 1706 are translated 
into standard object format. Generally a comprehensive 
library of all message types generated by the hybrid system 
is utilized to translate the correlated events into standard 
object format. Once the events are translated, they are ready 
for use by other system components, such as Fault Manage- 
ment or Billing. 

Customer Support Structure 

The organization model for customer service support in 
the NGN network provides a single point of contact that is 
customer focused. This single point of contact provides 
technical expertise in resolving customer incidents, troubles 
and requests. Generally a three tiered support structure is 
greatly increases customer satisfaction in service needs. 
Each tier, or level, possess an increased level of skill, with 
tasks and responsibilities distributed accordingly. . 

FIG. 18 is a flowchart showing a Three Tiered Customer 
Support Process 1800 in accordance with a preferred 
embodiment of the present invention. The Three Tiered 
Customer Support Process 1800 begins with a First Tier step 
1802. In step 1802, a customer with a hybrid network 
problem is provided access to customer support personnel 
having a broad set of technical skills. The broad set of 
technical skills allows this group to solve about 60-70% of 
all hybrid network problems. If the customers network 
problem is solved at this stage, the process ends. However, 
if the customers network problem is not solved at this stage, 
the process continues to a Second Tier step 1804. 

In the Second Tier step 1804, the customer is provided 
access to technical experts and field support personnel who 
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may specialize in specific areas. The greater specialized 
nature of this group allows it to solve many problems the 
group in step 1802 could not solve. This group is generally 
responsible for solving 30-40% of all hybrid network prob- 
lems. If the customers network problem is solved at this 
stage, the process ends. However, if the customers network 
problem is not solved at this stage, the process continues to 
a Third Tier step 1806. 

In the Third Tier step 1806, the customer is provided 
access to solution experts who are often hardware vendors, 
software vendors, or customer application development and 
maintenance teems. Customer network problems that get 
this far in the customer support process 1800 need individu- 
als possessing in-depth skills to investigate and resolve the 
difficult problems with there area of expertise. Solution 
experts are the last resort for solving the most difficult 
problems. Typically this group solves about 5% of all hybrid 
network problems. 

The above model is generally referred to as the Skilled 
Model because personnel at all three tiers are highly skilled. 
This model generally creates a high percentage of calls 
resolved on the first call. Other approaches include a Func- 
tional Model, and a Bypass Model. In the Functional Model 
users are requested to contact different areas depending on 
the nature of the incident. Calls are routed to. the customer 
support representative best able to handle the call. This 
model can easily be coupled with the Skill Model above. In 
the Bypass Model First Tier only logs calls, they do not 
resolve calls. One advantage of this model is that skilled 
resources don't have to waste time logging calls. 

In more detail, a customer calling a customer support 
center in accordance with one embodiment of the present 
invention is first asked a series of questions by an interactive 
voice response (IVR) system or an live operator. The cus- 
tomer uses Touch-Tone keys on the telephone to respond to 
these queries from the IVR, or responds normally to a live 
operator. 

When a product support engineer becomes available, the 
previously gathered information (both from the IVR query 
responses and the diagnostic information solicited from the 
system problem handlers and element managers) is available 
to the product support engineer. 

After reviewing the situation with the customer, the 
product support engineer can query the customer's computer 
via support agents for additional information, if necessary. 

In systems according to the preferred embodiment, the 
customer spends less time interacting with a product support 
engineer, and is relieved of many of the responsibilities in 
diagnosing and resolving problems. Automated diagnoses 
and shorter customer interactions save the product support 
center time, resources, and money. At the same time, the 
customer receives a better diagnosis and resolution of the 
problem than could usually be achieved with prior art 
product support techniques. 

In addition, one embodiment of the present invention 
makes the Internet a viable alternative to telephone calls as 
a tool for providing consumer product support. Many 
on-line computer services, such as Prodigy and America 
On-Line, provide, for a fee as a part of their on-line service, 
software for connecting to and accessing the Internet. 

The Internet access software accesses and "handshakes" 
with an "Internet Entry Server", which verifies the PIN 
number, provides the access and times the user's access 
time. The Internet Entry Server is programmed to recognize 
the PIN number as entitling the user to a limited prepaid or 
"free" Internet access time for on-line help services. Such a 
time period could be for a total time period such as 1 hour 
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or more, or access to on-line help services can be unlimited 
for 90 days, 6 months, etc., for example, with the access time 
paid for by the sponsor/vendor. The first time a customer 
uses the on-line help service, the Internet Entry Server 
5 performs a registration process which includes a number of 
personal questions and custom data gathering in the form of 
queries provided by the sponsor/vendor for response by the 
user. 

The pertinent answers are then immediately provided to 

10 the sponsor/vendor. The Internet Entry Server then "hot- 
links" the customer to the sponsor/vendor's Internet domain 
or Home Page for a mandatory "guided tour" where the user 
is exposed to any current product promotion by the sponsor/ 
vendor and can download promotional coupons, product 

15 information, etc. After this mandatory guided tour is 
completed, the customer is allowed to enter queries for help 
in installing or using the sponsor/vendor's product. As an 
optional promotional service, upon termination of the 
on-line help session, access to other information on the 

20 Internet can be provided. Once the "free" on-line help 
service time or time period is up, the Internet Entry Server 
prompts the user with one or more of a plurality of options 
for extending the availability of on-line help. For example, 
the user can be prompted to enter a credit card number to 

25 which on-line help charges can be charged; he or she can be 
given the opportunity to answer additional survey informa- 
tion in return for additional "free" on-line help; or a 900 
subscriber paid telephone access number can be provided 
through which additional on-line help will be billed via the 

30 normal telephone company 900 billing cycles. 
Integrated IP Telephony User Interface 
One embodiment of the present invention allows a user of 
a web application to communicate in an audio fashion 
in-band without having to pick up another telephone. Users 

35 can click a button and go to a call center through a hybrid 
network using IP telephony. The system invokes an IP 
telephony session simultaneously with the data session, and 
uses an active directory lookup whenever a person uses the 
system. 

40 FIG. 19 is a flowchart showing an integrated IP telephony 
process 1900 in accordance with a preferred embodiment of 
the present invention. The IP telephony process 1900 begins 
with a transmitting step 1902. In step 1902, data is trans- 
mitted over the hybrid network during a data session. This 

45 data session is typically a normal Internet browsing session, 
and is generally initiated by a web browser. Utilizing a web 
browser, users begin the data session by performing actions 
such as searching for web sites or downloading data from 
Internet sites. During the data session, the present invention 

50 allows users the option to initiate phone calls without the 
need to use another telephone. 

In a telephony step 1904, the present invention allows 
users to initiate and continue telephonic communication. 
The telephonic is routed by a user action in step 1906, when 

55 a user selects a phone number to call. Telephone numbers are 
typically included in a telephone directory accessible on 
screen by the user. In addition, the directory may include 
icons which provide a highly recognizable visual mnemonic 
to allow users to easily recall the information included in a 

60 particular directory entry. The present invention utilizes the, 
routing information to direct the call. Since both the original 
data from the data session and the new IP telephony data use 
Internet protocol, the present invention can provide a seam- 
less integration of the two, to provide virtually simultaneous 

65 telephonic and non-telephonic data communication. The 
availability of packet switching elements in the hybrid 
network facilitate this process. 
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In packet switching networks, packets in the form of units 
of data are transmitted from a source — such as a user 
terminal, computer, application program within a computer, 
or other data handling or data communication device — to a 
destination, which may be simply another data handling or 
data communication device of the same character. The 
devices themselves typically are referred to as users, in the 
context of the network. Blocks or frames of data are trans- 
mitted over a link along a path between nodes of the 
network. Each block consists of a packet together with 
control information in the form of a header and a trailer 
which are added to the packet as it exits the respective node. 
The header typically contains, in addition to the destination 
address field, a number of subfields such as operation code, 
source address, sequence number, and length code. The 
trailer is typically a technique for generating redundancy 
checks, such as a cyclic redundancy code for detecting 
errors. At the other end of the link, the receiving node strips 
off the control information, performs the required synchro- 
nization and error detection, and reinserts the control infor- 
mation onto the departing packet. 

Packet switching arose, in part, to fulfill the need for low 
cost data communications in networks developed to allow 
access to host computers. Special purpose computers des- 
ignated as communication processors have been developed 
to offload the communication handling tasks which were 
formerly required of the host. The communication processor 
is adapted to interface with the host and to route packets 
along the network; consequently, such a processor is often 
simply called a packet switch. Data concentrators have also 
been developed to interface with hosts and to route packets 
along the network. In essence, data concentrators serve to 
switch a number of lightly used links onto a smaller number 
of more heavily used links. They are often used in conjunc- 
tion with, and ahead of, the packet switch. 

In virtual circuit (VC) or connection-oriented 
transmission, packet-switched data transmission is accom- 
plished via predetermined end-to-end paths through the 
network, in which user packets associated with a great 
number of users share link and switch facilities as the 
packets travel over the network. The packets may require 
-storage at nodesbetween transmission links of the network 
until they may be forwarded along the respective outgoing 
link for the overall path. In connectionless transmission, 
another mode of packet-switched data transmission, no 
initial connection is required for a data path through the 
network. In this mode, individual datagrams carrying a 
destination address are routed through the network from 
source to destination via intermediate nodes, and do not 
necessarily arrive in the order in which they were transmit- 
ted. 

In a lookup step 1908, the telephonic communication over 
the hybrid network is limited bases on a user profile. 
Preferably the user profile is included in a rules database. By 
locating the user profile within the rules database, the rules 
database can provide seamless cross-location registration 
without the need for duplicate databases located on different 
networks. Using a rules database, a user utilizing the Internet 
in Europe can get the same telephony service as provided in 
the U.S., as described above. Preferably the computer used 
to interface with the Internet includes multimedia equipment 
such as speakers and a microphone. Utilizing a multimedia 
equipped computer allows a user to use telephonic commu- 
nication with little or no disruption while interfacing with 
the Internet. Multimedia computer speakers are used to 
receive the telephony audio from the network and the 
microphone is used to transmit the telephony data to the 
network. 
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Data Mining 

The present invention includes data mining capability that 
provides the capability to analyze network management data 
looking for patterns and correlations across multiple dimen- 

s sions. The system also constructs models of the behavior of 
the data in order to predict future growth or problems and 
facilitate managing the network in a proactive, yet cost- 
effective manner. 

l0 A technique called data mining allows a user to search 
large databases and to discover hidden patterns in that data. 
Data mining is thus the efficient discovery of valuable, 
non-obvious information from a large collection of data and 
centers on the automated discovery of new facts and under- 

J5 lying relationships in the data. The term "data mining" 
comes from the idea that the raw material is the business 
data, and the data mining algorithm is the excavator, shifting 
through the vast quantities of raw data looking for the 
valuable nuggets of business information. 

20 Because data can be stored in such a wide variety of 
formats and because the data values can have such a wide 
variety of meanings, data mining applications have in the 
past been written to perform specific data mining operations, 
and there has been little or no reuse of code between 

25 application programs. Thus, each data mining application is 
written from scratch, making the development process long 
and expensive. Although the nuggets of business informa- 
tion that a data mining application discovers can be quite 
valuable, they are of little use if they are expensive and 

3Q untimely discovered. Returning to the mining analogy, even 
if gold is selling for $900 per ounce, nobody is interested in 
operating a gold mine if it takes two years and $901 per 
ounce to get it out of the ground. 
Accurate forecasting relies heavily upon the ability to 

35 analyze large amounts of data. This task is extremely diffi- 
cult because of the sheer quantity of data involved and the 
complexity of the analyses that must be performed. The 
problem is exacerbated by the fact that the data often resides 
in multiple databases, each database having different inter- 
ne, nal file structures. 

Rarely is the relevant information explicitly stored in the 
databases. Rather, the important information exists only in 
the hidden relationships among items in the databases. 
Recently, artificial intelligence techniques have been 

45 employed to assist users in discovering these relationships 
and, in some cases, in automatically discovering the rela- 
tionships. 

FIG. 20 is a flowchart showing a Data Mining Process 
2000 in accordance with a preferred embodiment of the 

50 present invention. The Data Mining Process 2000 begins 
with an identifying step 2002. In step 2002, the system 
identifies patterns and correlations in the system data over 
the hybrid, communication system. Preferably the system 
data is analyzed across multiple dimensions to provide better 

55 future system behavior prediction. 

In a model building step 2004, the system builds a model 
of the network behavior based on the patterns and correla- 
tions identified in step 2002. Data mining is a process that 
uses specific techniques to find patterns in data, allowing a 

60 user to conduct a relatively broad search of large databases 
for relevant information that may not be explicitly stored in 
the databases. Typically, a user initially specifies a search 
phrase or strategy and the system then extracts patterns and 
relations corresponding to that strategy from the stored data. 

65 Such a search system permits searching across multiple 
databases. Hie extracted patterns and relations can be: (1) 
used by the user, or data analyst, to form a prediction model; 
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(2) used to refine an existing model; and/or (3) organized 
into a summary of the target database, as in predicting step 
2006. 

In a predicting step 2006, the system predicts future 
behavior of the network based on the model generated in 
step 2004. There are two existing forms of data mining: 
top-down; and bottom -up. Both forms are separately avail- 
able on existing systems. Top-down systems are also 
referred to as pattern validation," "verification-driven data 
mining" and "confirmatory analysis." Ibis is a type of 
analysis that allows an analyst to express a piece of 
knowledge, validate or validate that knowledge, and obtain 
the reasons for the validation or invalidation. The validation 
step in a top-down analysis requires that data refuting the 
knowledge as well as data supporting the knowledge be 
considered. Bottom-up systems are also referred to as "data 
exploration." Bottom -up systems discover knowledge, gen- 
erally in the form of patterns, in data. 

Finally, in a managing step 2008, the network is managed 
based on the future behavior of the network. Data mining 
involves the development of tools that analyze large data- 
bases to extract useful information from them. As an appli- 
cation of data mining, customer purchasing patterns may be 
derived from a large customer transaction database by 
analyzing its transaction records. Such purchasing habits can 
provide invaluable marketing information. For example, 
retailers can create more effective store displays and more 
effective control inventory than otherwise would be possible 
if they know consumer purchase patterns. As a further 
example, catalog companies can conduct more effective 
mass mailings if they know that, given that a consumer has 
purchased a first item, the same consumer can be expected, 
with some degree of probability, to purchase a particular 
second item within a defined time period after the first 
purchase. 

Classification of the data records to extract useful infor- 
mation is an essential part of data mining. Of importance to 
the present invention is the construction of a classifier, from 
records of known classes, for use in classifying other records 
whose classes are unknown. As generally known in the prior 
art, a classifier is generated from input data, also called a 
training set, which consist of multiple records. Each record 
is identified with a class label. The input data is analyzed to 
develop an accurate description, or model, for each class of 
the records. Based on the class descriptions, the classifier 
can then classify future records, referred to as test data, for 
which the class labels are unknown. 

As an example, consider the case where a credit card 
company which has a large database on its card holders and 
wants to develop a profile for each customer class that will 
be used for accepting or rejecting future credit applicants. 
Assuming that the card holders have been divided into two 
classes, good and bad customers, based on their credit 
history. The problem can be solved using classification. 
First, a training set consisting of customer data with the 
assigned classes are provided to a classifier as input. The 
output from the classifier is a description of each class, i.e., 
good and bad, which then can be used to process future 
credit card applicants. Similar applications of classification 
are also found in other fields such as target marketing, 
medical diagnosis, treatment effectiveness, and store loca- 
tion search. 

In data mining applications of classification, very large 
training sets such as those having several million examples 
are common. Thus, it is critical in these applications to have 
a classifier that scales well and can handle training data of 
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this magnitude. As an additional advantage, being able to 
classify large training data also leads to an improvement in 
the classification accuracy. 

Another desirable characteristic for a data mining classi- 
fier is its short training time, i.e., the ability to construct the 
class descriptions from the training set quickly. As a result, 
the methods of the invention are based on a decision-tree 
classifier. Decision trees are highly developed techniques for 
partitioning data samples into a set of covering decision 
rules. They are compact and have the additional advantage 
that they can be converted into simple classification rules. In 
addition, they can be easily converted into Structured Query 
language (SQL) statements used for accessing databases, 
and achieve comparable or better classification accuracy 
than other classification methods. 

Another data mining classifier technique solves the 
memory constraint problem and simultaneously improve 
execution time by partitioning the data into subsets that fit in 
the memory and developing classifiers for the subsets in 
parallel. The output of the classifiers are then combined 
using various algorithms to obtain the final classification. 
This approach reduces running lime significantly. Another 
method classifies data in batches. 

While various embodiments have been described above, 
it should be understood that they have been presented by 
way of example only, and not limitation. Thus, the breadth 
and scope of a preferred embodiment should not be limited 
by any of the above described exemplary embodiments, but 
should be defined only in accordance with the following 
claims and their equivalents. 

What is claimed is: 

1. A method for inter-network session control in an 
integrated packet based and circuit-switched based network, 
comprising the steps of: 

a) providing a subscriber home rules database located on 
a first network, wherein the database includes sub- 
scriber information; 

b) allowing a subscriber of the first network access to a 
second network having a remote session controller; 

c) providing the remote session controller a temporary 
copy of a portion of the subscriber information related 
to the subscriber; 

d) limiting access to the second network based on the 
subscriber information; 

e) transferring data relating to at least one of a service, 
feature, and information that is available to the sub- 
scriber on the first network from first network to the 
second network; 

f) making the data available locally on the second network 
for the duration of a session; 

g) allowing the subscriber to access on the second net- 
work the at least one of a service, feature, and infor- 
mation; and 

h) eliminating the temporary copy of the subscriber 
information and the data after a predetermined amount 
of time. 

2. A method as recited in claim 1, wherein the rules 
database determines routing preferences based on priority, 
cost, and termination location. 

3. A method as recited in claim 1, wherein the rules 
database further determines content separation by instruct- 
ing an intelligent peripheral and protocol converter to sepa- 
rate an audio stream from a data and video stream. 

4. A method as recited in claim 3, wherein the rules 
database further determines content separation by instruct - 
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ing the protocol converter to process the audio stream so as 
to enable the audio stream to be fed to a destination which 
supports traditional analog voice. 

5. A method as recited in claim 3, wherein the protocol 
converter interfaces with circuit-switched network elements 5 
to process information across the integrated hybrid network. 

6. A method as recited in claim 1, wherein the session 
controller provides systems management and reporting 
functions. 

7. A method as recited in claim 6, wherein the session 10 
controller acts as a hub for various applications. 

8. A system for inter-network session control in an inte- 
grated packet based and circuit-switched based network, 
comprising: 

a) a first network; 15 

b) a subscriber home rules database located on the first 
network, wherein the database includes subscriber 
information about a subscriber to the first network; 

c) a second network having a remote session controller, 2Q 
wherein the session controller is provided with a tem- 
porary copy of a portion of the subscriber information 
related to the subscriber; 

d) a processor that limits access to the second network 
based on the subscriber information; 25 

i) a processor that transfers data relating to at least one of 
a service, feature, and information that is available to 
the subscriber on the first network from the first net- 
work to the second network, wherein the data is made 
available locally on the second network for the duration 30 
of a session, wherein the subscriber is allowed to access 
on the second network that at least one of a service, 
feature, and information; and 

e) a processor that eliminates the temporary copy of the 
subscriber information after a predetermined amount of 35 
time. 

9. A system as recited in claim 8, wherein the rules 
database determines routing preferences based on priority, 
cost, and termination location. 

10. A system as recited in claim 8, wherein the rules 40 
database determines content separation by instructing an~ 
intelligent peripheral and protocol converter to separate an 
audio stream from a data and video stream. 

11. A system as recited in claim 10, wherein the rules 
database further determines content separation by instruct- 45 
ing the protocol converter to process the audio stream so as 

to enable the audio stream to be fed to a destination which 
supports traditional analog voice. 

12. A system as recited in claim 10, wherein the protocol 
converter interfaces with circuit-switched network elements 50 
to process information across the integrated hybrid network. 

13. A system as recited in claim 8, wherein the session 
controller provides systems management and reporting 
functions. 
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14. A system as recited in claim 13, wherein the session 
controller acts as a hub for various applications. 

15. A computer program embodied on a computer read- 
able medium for inter-network session control in an inte- 
grated packet based and circuit-switched based network, 
comprising: 

a) logic that provides a subscriber home rules database 
located on a first network, wherein the database 
includes subscriber information; 

b) logic that allows a subscriber of the first network access 
to a second network having a remote session controller; 

c) logic that provides the remote session controller a 
temporary copy of a portion of the subscriber informa- 
tion related to the subscriber, 

d) logic that limits access to the second network based on 
the subscriber information; 

e) logic that transfers data relating to at least one of a 
service, feature, and information that is available to the 
subscriber on the first network from the first network to 
the second network; 

f) logic that makes the data available locally on the second 
network for the duration of a session; 

g) logic that allows the subscriber to access on the second 
network the at least one of a service, feature, and 
information; and 

h) logic that eliminates the temporary copy of the sub- 
scriber information and the data after a predetermined 
amount of time. 

16. A computer program as recited in claim 15, wherein 
the rules database includes logic that determines routing 
preferences based on priority, cost, and termination location. 

17. A computer program as recited in claim 15, wherein 
the rules database further includes logic that determines 
content separation by instructing an intelligent peripheral 
and protocol converter to separate an audio stream from a 
data and video stream. 

18. A computer program as recited in claim 17, wherein 
the rules database further includes logic that determines 
content separation by instructing the protocol converter to 
process the audio stream so as to enable the audio stream to 
be fed to a destination which supports traditional analog 
voice. 

19. A computer program as recited in claim 17, wherein 
the protocol converter interfaces with circuit-switched net- 
work elements to process information across the integrated 
hybrid network. 

20. A computer program as recited in claim 15, wherein 
the session controller provides systems management and 
reporting functions. 

21. A computer program as recited in claim 20, wherein 
the session controller acts as a hub for various applications. 

* * * * * 
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